Archive

Archive for August, 2010

Marcato Welcomes Riley Horan!

August 30, 2010 Leave a comment

Marcato is pleased to announce the addition of a new team member and long-time voice for healthy Agile teams in the Twin Cities Area – Riley Horan.

Riley Horan

Riley has worked with several organizations in the Twin Cities including Wells Fargo, Thomson Reuters, Gelco Trade Management, and Internet Broadcasting in both Technology and PMO Management.  He has delivered SAAS solutions in the consumer goods industry and SOA enterprise applications in the financial services industry, and led the agile adoption initiative at Internet Broadcasting.

Riley’s passion is building engaged and productive teams by finding individual strengths and melding them into the overall team structure.  His loves to help people find what they do best and then reach their potential.  Since building great products and sustainable teams is so dependent on great communication inside and outside of the team, his personal interests include enhancing interpersonal dialog and meeting facilitation.

If you would like to get to know Riley better, then check out his most recent addition to the Marcato blog – How Healthy Is Your Team?

Categories: Marcato

How Healthy Is Your Team?

August 30, 2010 Leave a comment
In general, work can be divided into three domains: business, technology, and people.   Business, centers on your customers’ industry, products, competitors, competitive advantage, and markets.  Technology involves supporting the business domain via innovation, product delivery, efficient systems, trends, costs, and tools.  The People domain focuses on the the individuals in your business and how they interact with each other to solve business problems, deliver products, and technology solutions.  The People domain is my special interest as it is the most personally fulfilling.

Typically, the People domain receives the least amount of focus within companies. Why? In most organizations, career advancement requires being an expert in business or technology.  The relevant knowledge and information required to make a decision, provide customer support, develop product marketing is what gets you recognized.  It is our survival instinct within the corporate jungle.

Even though most corporate value statements incorporate people or employees as a key value, this value most often receives the least amount of executive attention and investment.  It is difficult for ambitious, hard driving, and self-reliant people to rely more on building a team to deliver, than ensuring on getting the job done themselves. If you truly want to create, build, and sustain a company that is successful for the owners, the customers, and employees, the old adage, “If you take care of your people, they will take care of you” provides the needed guidance.

Interestingly, there has been a renewed focus on the human aspect in business literature.  You can’t peruse the Barnes and Noble business section these days without seeing many books about psychology, intrinsic satisfaction, motivations, beliefs, strengths, dialog skills, fears, tendencies, and talents.  Information in these areas is becoming more accessible, relevant, and understandable to the average business or technology professional.

An operational definition for Agile relates to the People domain: A way of bringing individuals together, forming and interacting within a team, for the purpose of building great product.  The Agile manifesto provides the framework to help guide, but not dictate, how individuals come together.  My favorite value is, “Individual and Interactions over Process and Tools”.  This is important because it addresses the most critical aspect of any organization – healthy interactions and employee engagement.  (You know you have drunk the Kool-aid when you have a favorite value.)

There is something magical when you are on a team and everything is clicking.  People are talking openly.  People are laughing, having fun and developing great products and services.  People work together under pressure, but are not stressed.  Below is a way to measure how healthy is your team or organization or identify where your problem areas exist.

The most common measurement of a company’s health is the annual employee engagement survey.  The surveys identify major trends but rarely drill down to a level that pin-points problems and identifies corrective actions.  These four categories can assist with energizing people, increasing engagement, and creating teams that are truly sustainable beyond the short term success of one product launch.

Environment – This is an individual’s direct physical environment and how it enables team interactions as well as the tools, processes and practices utilized to interact with other individuals.  Are individuals physically working closely with other team members, or can connect to quickly?  Does the environment support quick and seamless interactions and sharing of information?  Or, is the sharing of knowledge and communication among team members a difficult and hinders productivity?

Mental – When people are working as part of a team are they performing tasks that they actually enjoy and look forward to doing?  Will those activities make them better and more successful?  Or, are they doing work that is not a good match and does not excite them?   Do the individuals on a team truly know what they are good at, and why?  Do the team members understand each other’s strengths and know how to fit them into the larger team structure?

Emotional - Having or not having healthy dialog with other team members can put a strain on an individual’s emotions.  Do people complain about decisions and people after meetings and at lunch?  Do people not say what is on their mind because they fear reprisal? Are people stepping up to having hard conversations? Do they have the skills to engage in truly emotional and difficult conversations?

Mission – Great team’s need missions to rally around; a core mission that everyone believe in and support.  This is the bond that inspires and keeps the team together.  It is something that is greater than the individuals themselves; they willing share the joy and sacrifice together.  The mission’s idea needs to be simple and easily articulated and understood to truly take hold and energize a team.

These four categories taken together and combined create true engagement, increase productivity, and sustain success.  When one category is in limited quantity, the immediate product may be delivered through force of a leader’s personality or extrinsic rewards like bonuses; however, the short-term success cannot be sustained nor will the team continue to gain momentum.

What can you as a director, front-line manager, project manager, or team lead do to ensure your team’s current and future health is well and sustainable?  Branching into the People domain is a good first step.  Most people have simply not been trained to fully understand the needs of an individual, to understand the individual’s strengths, and figure out how to help this person reach full potential.  In reality, this knowledge is lifelong quest in various disciplines.

You can start now with small steps.  You can look at people with whom you work the closest to and ask, “Am I doing everything that I can do to help these people be successful?”  If the answer is “No”, then ask someone “How can I help you?”.  Better yet, meet with your team and have them ask, “How we can help each other?”  The human aspect of a team often gets lost in the rush to deliver product; taking the time to understand the team and the individuals is critical for long term success.

At Marcato Partners we are examining each of the four categories and will be discussing them in more detail in the coming weeks.

If you want to discuss the concepts or more information please contact Riley@MarcatoPartners.com.

One of my favorite quotes – “The needs of the team are best met, when we meet the needs of the individual” – Max DePree.

Categories: Interactions

Allegro

August 29, 2010 Leave a comment

Marcato is approaching it’s first year anniversary – September 9th!  And lest you think this means things are slowing down here, the exact opposite is true; in fact, there are several significant changes under way.

Announcing Marcato World HQ!

Marcato World HQ - Anoka, MN

While much of our work is directly with client teams and is often on site, we found that our work often allows the flexibility to work remote and that home offices and coffee shops can be less than ideal for being able to focus and communicate.  As you’ll learn in the next section, we also wanted to have a shared space we could use as we start pursuing more common projects together.  We chose downtown Anoka as the location and we now have a fully armed and operational battle station.  While the local amenities and 10 minute commute are certainly enjoyable, the best part is having a common place to work together.

Here are a few more shots of the local area courtesy

of our resident photographer – Tracy Knighton:

Marcato World HQ - Anoka, MN

Home of Marcato - Anoka, MN

Sneak Peak at Allegro

Agile coaching runs deep in the Marcato DNA, but so does using that methodology and our technical skills to build new products.  With this in mind, we at Marcato have found that we have a unique combination of skills and experiences to be able to apply those principles to helping small startup organizations get from idea to proof of concept and well beyond.  We understand when and how to establish Agile development practices light enough to serve the smallest of teams but capable enough to grow with your organization through later funding rounds.  We also know how to use that hard won capital efficiently and will help expand your development capability to using low cost development resources as you move towards productizing your ideas.

Main Street - Anoka, MN

Gateway to the City - Anoka, MN

Allegro Phase 1

Marcato is working closely with a new client still in stealth mode to test our new service offering by helping them to build out a demonstration of the core ideas for their new product and to support their partnering and fund raising efforts by providing a technical team that can set the architectural direction as well as deliver the goods. We’re also working closely with our good friends at Whoop Design on this one – stay tuned for more!

Categories: Marcato

Marcato Presentation on Sept. 2: Caching with Velocity

August 28, 2010 Leave a comment

Sign Up!

Please join us Thursday, Sept 2nd for the Twin Cities .NET User Group Meeting! Pizza will be served at 5pm, courtesy of ILM; Beverages will be provided by New Town. The speaker will begin at 5:15pm. The meeting will be held in the Microsoft Offices in Bloomington: 8300 Norman Center Dr., Suite 950.

Title: Everything You Wanted to Know About Velocity But Were Afraid To Cache

Microsoft’s AppFabric Caching (aka Velocity) offers a distributed caching solution, not unlike the popular “memcached” open source library. It allows you to increase scalability and performance by caching data physically (and logically) closer to the consumer. It can help you dramatically increase responsiveness of your apps and services, as well as relieve pressure on back-end resources. Come and hear about the concepts and terminology, as well as deployment considerations, typical usage patterns, pitfalls, and more.

Speaker: Scott Colestock

Scott Colestock lives and works in the Twin Cities. He has been consulting for the past fifteen years, spending time in a variety of areas with performance and process as common threads. He is most recently a partner at Marcato (marcatopartners.com), which focuses on delivering agile coaching services. He is also a BizTalk MVP, performance engineering guy, and “Team Foundation Server + Scrum” resource.

And don’t forget to sign up for these great upcoming conferences:

Minnesota Developer’s Conference, Sept 29th:  http://mdc.ilmservice.com/Register.aspx
Twin Cities Code Camp, Oct 9th – 10th:  http://tccc9.eventbrite.com/

Categories: Shipito Ergo Sum

Top 10 Tweaks to Agile/Scrum – Part 2

August 22, 2010 Leave a comment

Agile is a set of principles to guide how you organize and function as teams and Scrum is a particular system for establishing and building a delivery rhythm within that team.  Part 2 examines 5 more examples of common changes made to Scrum and the reasons why these are counter to what the system is trying to accomplish.

6.  Set “stretch” goals by putting more stories in the sprint than fit within the velocity

To create a sustainable rhythm, you have to set goals for the team that can be met with regularity.  If it requires heroics to accomplish one sprint, then heroics become the norm for future sprints as your team velocity adjusts to account for this.  New teams often fall prey to this phenomena – their energy for the project and desire to make a good impression on their product owner gets the better of them.  They let the product owner put more stories into the sprint than is prudent because their uncertainty about their actual velocity opens the door for the usual optimism of a development team.  They try to shoehorn in just one more story because they are interested in the technology or feature and want to try to make it fit.

Japanese Lantern Lighting Festival, Como Park

This kind of persistent inflation in velocity is unsustainable – like with any economy, real growth can only come from an increase in resources or in the productivity of the existing resources.  You will see this happen through the productivity that comes from climbing the learning curve, but that always levels out eventually.  What’s the downside?  In the short run, disappointments happen, and instead of giving the team the opportunity to establish and celebrate a pattern of successes, they are instead frustrated by a string of missed goals.  In the long run, left unchecked this behavior leads to burnout and turnover as you find yourself trapped in a “death march” of unsustainable expectations.

7.  Give credit for a story when it is not really done (shippable)

Yes, it feels good to show off your work in the sprint review and to claim victory, but with each passing event where “done” is not really done, your team has taken on a future debt that must be repaid.  These schedule bombs don’t go off until much later, long after the fuse is lit, and usually at the most embarrassing and inconvenient times.  Also, once you compromise on this a little it becomes a slippery slope of lowering expectations as individuals vie for credit for their work.  We all know that product owners can be fooled in a demo, so acceptance by the product owner is not really enough.  Instead, the scrummaster and testers should hold firm to the team’s definition of success and only agree to take credit when credit is due.

8.  Increase length of sprint so that more stories can get finished

It’s the day before the end of the sprint and you can see that there are a couple key stories that are not going to make it.  They are big stories, so without these your velocity will be less than half what you expected and the optimistic outlook from the team is that they could get them done if they only just had one or two more days.  Someone on the team suggests that it would be better to extend the sprint than to arbitrarily end it now when you are so close.

Japanese Lantern Lighting Festival, Como Park

Usually this behavior indicates several forces are at work – stories are too big, too many stories are being worked on in parallel, and the team may not be doing enough detailed planning at the start of the sprint to have clarity on what will be built.  Since software is a gas that expands to fill 110% of the space provided, if you extend the sprint to let that last 10% in, then you will learn nothing from your mistakes and just do the same for the next sprint.  You also sacrifice your rhythm, these last minute changes in expectations confuse everyone as you try to figure out who has the authority to change the rhythm and who is responsible for communicating the new plan.  Leave the plan alone, examine in your retrospective what really went wrong, and fix it so it doesn’t happen again.

9.  Cut sprint short because all “bought” stories are complete

Japanese Lantern Lighting Festival, Como Park

This is more of a “minor sin”, but interrupting the rhythm just confuses everyone – you are better off to find other small stories to add to the scope until the time is up than to break the rhythm.  Be careful not to start big stories that you can’t finish – this just leaves the product in an unstable state as you are trying to demonstrate it and threatens the principle that the product be shippable at the end of the sprint.

10.  Estimate during sprint planning meeting

This observation is controversial as there are certainly going to be situations where you are forced to do this by no apparent fault of your own, so if you find yourself in that situation, then by all means just do it.  But first understand the risk you are taking – you are estimating the story in isolation, perhaps by a different collection of people than normally estimate, and you are doing so in the context of already knowing you want it in the sprint and you just need to decide if it will fit.  This probably means you already know how big you need it to be, so you are anchored on this answer.  What happens in this situation?  The estimate comes in to magically fit and round out the sprint and the most common reality is that you underestimated its complexity.

Categories: Shipito Ergo Sum

Top 10 Tweaks to Agile/Scrum – Part 1

August 7, 2010 Leave a comment

I spent this week with a new client doing training on Agile and Scrum and wrapping up with workshops where we laid out specific plans and timing for rollout of Agile.  It was an exhausting but rewarding experience and it was fascinating to see another organization go through the early stages of the change process.

One aspect of teaching Agile and Scrum that makes it easy is that it is so hands on – the curriculum is designed to get people into teams and to learn how to problem solve, reach consensus, and communicate as a team – and this is part of why it is fun to learn.  The feedback (not surprisingly) is that people enjoy the team exercises and real world examples about what has worked and not worked in other situations.

Since I enjoy thinking about and studying organizational dynamics, one of my favorite parts of teaching Agile is to try to help people understand how the mechanics of the system are designed and why messing with those mechanics in simple ways can have interesting side effects and repercussions.  We teach the values of Agile before the mechanics of Scrum for exactly that reason – most of the explanations for "why?" something is handled the way it is derive from reinforcing the values behind the process.

While there were many enjoyable moments, my favorite was a group discussion we had around a Top 10 List of most common tweeks to Agile/Scrum.  The idea behind the exercise is to throw out things that they are probably already thinking about doing, but then to encourage them to think about what happens if they do them and what the consequences of changing the system might be.  This was probably one of the most interactive parts of the training as you could see the light bulb going on for many in the room.  Here’s what we discussed:

1.  Change the duration of the sprint in calendar days because of known changes to capacity

This is a "minor sin" but still not a good idea – I know that when you are getting cut short on resources during a heavy vacation period, it’s easy to want to stretch things out, but all this does is further disrupt the rhythm and leave people wondering what is going to happen and when.  Better to just drop your velocity a commensurate amount and stay on rhythm.

2.  “Split the difference” in story point estimating when the team gets stuck

Another "minor sin", but still indicative of a problem that can be better solved another way.  Usually this is happening to the larger point values (the jump from 20 to 40 is tough to swallow) and represents a sharp divide in opinion within the team as to how complex the story is because it is so large.  The best remedy is to break the story down into smaller stories, but if that fails you are probably better of using the higher point value.  I know that splitting the difference can help you feel like both parties are giving something up so it seems more fair, but odds are the worst case estimate is actually more accurate, especially if it is coming from the person that happens to know that part of the product well.

3.  Change estimating process because we are consistently under-estimating

This one is more of a "major sin" because it can have serious consequences.  The theory behind estimating is that it does not have to be accurate to work but it does have to be stable.  If the estimating team consciously decides to shift its bias in how it estimates depending on the outcome of the previous sprint, then velocity will become unstable.  If you study system design, you learn that delays in feedback loops always introduce instability into the system.  Far better to keep your estimating process stable and let your velocity change to account for the real variation in productivity.

4.  Give bugs story points

I would call this a "major sin" as well because it strikes right at the heart of Agile values.  Story points are a proxy for "value" – they are the credit or reward we give to a team for doing something that the customer values.  Do customers value bugs in the product?  Absolutely not – in fact, it might even be more accurate to give them negative story points instead of zero.  There is one exception I have made to this rule – when you are trying to get a new team to embrace improving the quality of a legacy product that they did not create, then it is hard to get them motivated to solve the problem unless you give them credit for doing the work.  However, as soon as bugs start to show up in new work they have done or caused by other bug fixes they are making, then you need to go back to giving them zero story points.

5.  Separate feature testing into a later sprint

This one is somewhere in the range of "major sin" to "mortal sin" yet is surprisingly common.  There are kinds of testing (such as the development of new automation testing or full regression testing) that truly are impractical to commit to in every sprint, but I think once a team starts down this slippery slope, they conclude that this should mean that all test activities have until the end of the next sprint to complete.

It’s hard to summarize in a few words why this is so harmful to the system, but my best suggestion is to read the book "The Goal" by Eli Goldratt if you really want to grok the risks to the system.  When you decouple software testing from development, then test activities regress from process control to inspection and you lose your ability to determine if development or testing is your process bottleneck.  Separating when developers and testers work on features also violates one of the most important Agile values – Individuals and Interactions.  If they work on the feature together, they will both be available and motivated to work through it as a team.  If you separate it in time, then the quality of the interaction will drop dramatically.

Stay tuned for 5 more!

Categories: Shipito Ergo Sum
Follow

Get every new post delivered to your Inbox.