Transparency in Agile Projects, Not Emperor’s Clothing

Transparency is the Fabric of Agility

Apparently insecurity about expressing truth and transparency is not a new problem.  Published back in 1837 by Hans Christian Andersen, “The Emperor’s New Clothes” accurately describes a phenomenon alive and well today.  In a nutshell, weavers (con men) convince an arrogant ruler who only cared for appearances, that their wonderful new fabric is invisible to those who are stupid or unfit for their position.  The ruler purchases clothes made of this fabric from the weavers so that he can expose those around him who are unfit.  The fear of being viewed as unfit leads the emperor and all those around him to openly admire the new clothes, reinforcing the illusion of widespread support.  It takes an innocent child with no agenda to point out the obvious truth – the emperor is not wearing any clothes.

Yes this analogy has been drawn many times.  We laugh at the story, but do we still fail to see the parallels in our own behaviors?

Cat in a Box

In business projects, the phenomenon looks something like this… The manager brings forth the plan and everybody readily agrees with it despite individually realizing there is little chance of success.  Regularly they parade to status meetings and with great pomp and circumstance, proceed to report how all is good and they will get it done (somehow).  Secretly, nobody including the customer believes this is likely, yet nobody dares to speak of this out of fear of looking incompetent.  Secretly, and then only with their deepest confidants, some will laugh at how clueless others are to actually believe this is workable.  Heck, even the manager doubts it, but won’t admit it either, also for fear of looking unfit.  Much effort goes into maintaining the grand illusion.  This goes on to the point that it is essentially woven into the fabric of the culture as they actually become to believe in false realities. Communal reinforcement becomes the norm.

Emperor New Clothes

Why does this paradigm persist so prominently still?  Why indeed is curious because the results are not good….

Customers lose faith.  Reality is that they rarely get what they really need, when it was promised or for the budget they agreed.

Project teams lose motivation.  They do not want to fail.  Quality suffers in an effort to get something delivered and they suffer burn-out through endless pressure to find a way.  They begin to feel hopeless and overcome by technical debt.  Productivity and morale suffer.

Managers desperately seek to hold it all together and their stress level rises as well.

Curious indeed – why would competent individuals run a business this way?  Reality always wins eventually, though some are good at maintaining the fantasy a long time.  So, why do some individuals enforce such a norm when actually each would prefer the truth?

Well I am not a psychologist.  But logically the behavior seems rooted in an inner insecurity and fear.  Humans are social wanting acceptance from others. Sometimes we assume that others are smarter and thus must be correct, leading us to doubt what we really know.

The larger the group, the harder it is to speak against the perceived majority position. The more challenging the project, the more likely we are to look to others for confirmation and question our own knowledge.  And when a person of recognized authority is setting the tone, the less likely their position will be openly challenged.

We won’t realize the benefits of agile until we face some of the human psychological barriers that inhibit change, even good change.  Logically we can see how agile works.  Yet, it still does not work well in many organizations or at least to its fullest potential.

Real change requires someone to come forward and simply tell the truth about reality.  That simple act alone can start a domino reaction of healthy change in cultural norms.  False realities are fragile and not sustainable long term.  Mere facts, data, and simple truth are their downfall.  Likely most others are not wanting to promote the false norm either, but do not realize that there are others like them.  So, one brave soul really can change everything.

Now ask yourself, is your organization truly transparent?  Are you really sure?  Does the culture promote openness?  Can project members be candid without fear of reprisals?  Cultural barriers to openness and transparency are significant impediments in truly becoming agile.

First clearly reinforce that transparency and openness are core values of your organization.  Set the standard, demonstrate it, and live by it.   Accept nothing less at all levels.  Remove any appearance of negative consequence for openness.  If you find candid response lacking, explore why without condemnation.  Organize people into small project teams as it is easier to be open within a small group (like agile framework promotes).

Maybe your organization just does not have the means to objectively assess true project status without emotional basis?

There is a simple solution and it takes the whole communal reinforcement problem out of play – use an agile project management system to objectively capture real-time project status automatically providing total transparency.  Review project status data pulled in real-time.  Burn-down charts and project dashboards provide immediate real status.  Make sure your teams are committed to accurate tracking and then trust what the data is telling you.  Real data communicates reality.  In Scrum, velocity enables forecasting based on proven performance.  Let measured velocity forecast project results with objective data.  Now nobody feels pressured to provide what they perceive somebody wants as an answer.  Let the facts speak.  Learn to trust the power of velocity.

Let transparency unlock real project team engagement and improve your business agility.

Is project transparency a problem?  Have you seen these behaviors?  Why does it persist?  How did you succeed in changing it?  Please share your comments and observations.

Posted in Agile Adoption, Agile Management, Agile Project Management | Leave a comment

First Things First: Scale Agile Values and Principles

Over the past few years there’s been an interest in scaling agile to the enterprise.  The desire to scale agile seems to have intensified over the last year, in particular.  Almost without exception, every conference remotely related to software development and/or project management seems to have some presentation on the topic of scaling agile.  I believe this is being done with the best of intentions but, in my opinion, it misses the point on at least three levels.

First, almost all of the discussions I’ve heard, and most everything I read, refers to scaling aprocess.  I can understand why so many are looking at the process first—because it’s easier; well, until they actually start at which point they discover it’s not so simple after all.  One of the reasons they immediately encounter difficulty is that the enabling factor of scaling is not yet in place.  I know it may sound cliché at this point, but please recall the first line of the Agile Manifesto which states that we value “individuals and interactions over processes and tools.”  One of the primary reasons companies struggle so mightily with agile adoption, not simply with scaling, is because the enabling behavior and attitudes are either lacking or totally nonexistent.  They’ve either forgotten to consider individuals and their interactions, ignored them completely, or undervalued the importance of the human element.

Agile methods are based on empiricism, which implies adaptation based on observations.  In short, it is not a control mechanism—especially of people.  In fact, I’m beginning to strongly believe we should stop talking about scaling process entirely—at least for the time being; rather, focusing our attention on de-scaling process through the introduction of replicated Lean Startup models such as the one Spotify has adopted.  My colleague, Brian Watson, also discussed this premise in a blog post titled Agile Killed the Project Star.  If you’d like an introduction to the Lean Startup, the video below summarizes the concept .

Secondly, I fear that leaders genuinely desire the results agility promises (faster delivery, higher quality, improved morale, etc.) but do not want to first address their own behavior. They’re perfectly ready and able, but not truly willing. I constantly hear the lip service, but rarely witness the behavior demonstrated. The dissonance I see repeatedly is as follows:

Lip Service: I want teams to be self-organizing, self-sufficient, and deliver value quickly to the customer with high quality;

Behavior Demonstrated: I don’t want to let go of the control I’ve worked so hard for and hold dearly. I must be able to leverage my personal authority – otherwise, what value does my authority bring?

This is a dysfunctional and destructive attitude for your teams, your organization, and your shareholders. For an agile leader, the value of your authority is that you have power to remove organizational and bureaucratic barriers impeding the progress of teams—exercise your authority through servant leadership. It’s amazing the change you’ll see in others as a result of first changing yourself. Reread that sentence again and stop to let it firmly embed itself into your psyche. To put it another way, you do not deliver value; you enable value delivery. I wrote about this topic last year in a blog entry titled What’s Your Role: Umbrella or Funnel?

Finally, when people speak of scaling agile they are usually talking about IT or software development—the technologists. This is about so much more than software development. The agile values and principles offer a promise of a more innovative way of managing and working in a creative era than the hierarchical control mechanisms invented by Frederick Winslow Taylor used to manage Industrial era assembly line work. Unfortunately, this is still the predominant management technology used today.

To extract maximum organizational benefit, consider embracing agile throughout the entire value stream. I’m talking about adoption that begins at front-end sales all the way to back-end support and customer service. The only question is, are you willing to adopt the behaviors and attitudes (as an individual) necessary to enable this type of change?  I’ve created additional content beyond what’s in this blog if you’d like to further explore A Case for Building the Agile Company.

Posted in Agile Adoption, Agile Benefits, Agile Management, Enterprise Agile, Scaling Agile | 6 Comments

Why I Love Scrum

Gonna keep this short and sweet… I’ve been practicing Scrum for about 7 years now. And in my experience, it just flat out works. It’s simple, fun, and it brings people together, which is something that can be hard to do in the IT business. We get stuff done. The quality is high (assuming we’re including Agile testing best practices, like automation, unit testing and TDD). And more importantly, we deliver to the customer what they want now, not something they asked for 12 months ago.scrum_good

The beauty of Scrum, in my mind, is in our ability to inspect and adapt often. No more ‘death marches’. No more spending a ton of time up front (analysis paralysis). No more delivering a buggy product because we had a set date and only a small window to test. And no more producing something that isn’t used; a good Product Owner simply won’t allow it.

That said, Scrum is hard. It takes a change in mindset in how we work. As a former Project Manager, my days of defining a schedule up front and harassing people to meet unrealistic dates is thankfully over in my new role as Scrum Master. Scrum is based on reality. I’ve seen entire changes in corporate culture as a result of instituting Scrum. Folks don’t go back to their cubes, put their headphones on, and tune out for the projects’ entirety. We work together better in Scrum teams. We meet daily. We’re co-located. We talk. We understand each others’ issues and help resolve them straight away. We step outside our comfort zones. We have honest conversations, without repercussions. We trust each other. Transparency is high. It’s powerful. And best of all, it’s simple if people open their minds to new ideas.

Not everyone is a great fit for a Scrum team. I’ve experienced this first hand with folks who just don’t want to change. They don’t see the need. Admittedly, Waterfall still works for those more predictable efforts. But most software development isn’t predictable. In fact, it’s very unpredictable and requires a high degree of creativity and flexibility.

So yeah, change is hard; I get it; it’s human nature. But if you’re willing to let it, Scrum can be pervasive in your organization, given time to take root. Everywhere I’ve used it, most folks love it. It’s an easy sell to your boss if you want to champion it in your organization. Check out our Agile Sherpa site for more information if you’re thinking about making the switch, or just getting started.

www.agilesherpa.org

For those of you who’ve tried Scrum and don’t like it, I’d like to hear your thoughts. Let’s get a conversation going.

Posted in Agile Adoption, Agile Benefits, Agile Development, Agile Management, Agile Methodologies, Agile Project Management, Agile Teams, Scrum Development, Scrum Methodology, Scrum Software, Scrum Tools, Uncategorized | 6 Comments

Boulders to Gravel: Techniques for Decomposing User Stories

I’d like to open by acknowledging that user stories should be the start of a conversation. At some point that discussion should result in a confirmation of what is to be delivered. Teams and individuals new to agile commonly struggle with breaking large user stories into smaller ones—turning boulders into gravel, to make a cliché analogy.

Too often, Big to Little Rocksteams commit to stories that are simply too large to reliably complete in a Sprint time box; they’re epic user stories.  For new agile teams, this is understandable; it’s a new way of working and they’re used to working on larger deliverables.  However, agile teams that are established may also frequently struggle with work decomposition.

So, exactly how big should user stories be before they’re pulled into a Sprint?  The truthful answer is—I don’t know, it’s situational and relative.  My recommendation is that, if you’re going to pull a user story into a Sprint, the team should be able to complete it in one or two days.  I suggest this for several reasons:

  1. Small stories are usually less complex, which helps make them more understandable, leading to a story that’s easier to estimate.  More reliable estimates lead to an enhanced collective team confidence in meeting Sprint commitments;
  2. Small stories usually equate to shorter cycle times, thereby reducing the time it takes to deliver business value to the customer;
  3. Finally, large user stories hide bottlenecks and impediments.

Below are four techniques that you might not have considered for decomposing user stories that you can use to make gravel out of your own boulders.  I learned these from Chris Sims in my Certified ScrumMaster (CSM) class several years ago and I have successfully applied them numerous times; not yet finding a story that can withstand the scrutiny of all four techniques.

In the below examples, I’ve used the widely accepted user story format:

As a <user persona>, I want <desired functionality> so that <definition of value>.”

I’ll be using a banking system to demonstrate the techniques with easily relatable and practical examples.

Conjunctions and Connecting Words

Examine the user story for connecting words, such as conjunctions that can be used to separate the story.  As an example consider this user story:

As an online banking customer, I want to be able to check my account balance and transfer funds so that I can manage my account properly.”

New Stories:
(1) “As an online banking customer, I want to be able to check my account balance so I can ensure I have enough funds for transactions.
(2) “As an online banking customer, I want to be able to transfer funds so I can have sufficient funds available in all of my accounts.

Generic Words

For purposes of this discussion, I’m defining generic words as being those that are vague and/or subjective.  Replace these words with one or more words that are specific and descriptive.  Consider the following story:

As an ATM user, I want a user interface that is easy to navigate so I can quickly find what I want to do on the screen.”

What, exactly, does “easy to navigate” mean?  It could mean different things to different users.

New Stories:
(1) “As an ATM user, I want an interface that has a home screen containing the three transaction options available so I can perform a transaction.
(2) “As an ATM user, I want an interface that has a home screen containing an option to cancel a transaction so I can choose to abort if I’ve made a mistake.

Note also that new story (1) above could be further decomposed into three stories by writing one for each of the three transaction options (deposit, withdraw, transfer).

Acceptance Criteria

In addition to conjunctions, connecting words, and generic words you can also examine acceptance criteria to identify potential areas you may be able to split a story.  Consider the story outlined below, that encompasses a large part of an online banking system.

As a banking customer, I want to be able to do my banking online so I can do routine transactions from anywhere.

Here are example acceptance criteria for this story:
- Members must be able to check balance of each account.
- Members must be able to open a new account.
- Special offers for members are displayed when they open the site.
- Members must be able to transfer funds between accounts.
- Members must be able to communicate with bank staff to have questions answered.

New Stories:
(1) “As an online banking customer, I want to check the balance of my accounts so I can know how much money I have in each account.
(2) “As an online banking customer, I want to open a new account so I can expand my money management options.
(3) “As an online banking customer, I want to see offers available to me so I can take advantage of savings I’m eligible for.
(4) “As an online banking customer, I want to be able to transfer funds between accounts so I can have sufficient funds available in all of my accounts.
(5) “As an online banking customer, I want the ability to communicate with bank staff so I can have my questions answered.

By simply examining one user story’s acceptance criteria, five smaller stories have been created that can provide value to members much more quickly than waiting for the entire user story as originally written.

Timeline Analysis

To use timeline analysis, imagine the story has been implemented and delivered.  How does the story get used?  What is the logical sequence of events that describe its use?  Each of these steps may be a valid story that could be implemented independently.  Consider this story:

As an online banking customer, I want to pay bills online so I don’t have to mail a paper check to a creditor.”

At first glance, online bill pay may not seem that large.  However, let’s create some user stories based on a process flow that a typical online user performing an online bill pay transaction may need to perform.  Doing this exercise may lead to the following sampling of smaller user stories, each comprising a step in the online bill pay functionality.  Of course, this is just an example and is certainly not an exhaustive list.

New Stories:
(1) “As an online banking customer, I want to enter creditor information online so I don’t have to re-enter each time I have to pay a creditor.” (Data entry GUI?)
(2) “As an online banking customer, I want to select a creditor I’ve paid in the past so I can pay a bill that is coming due.”  (Creditor database?)
(3) “As an online banking customer, I want the ability to schedule automatic bill payment so I can ensure my bills that are due on a specific day each month are never past due.”  (Server-side scheduled transaction?)
(4) “As an online banking customer, I want a transaction receipt for a bill that I’ve paid emailed to me so I have proof that I’ve paid.”

Try these techniques at your next backlog grooming session and help your team decompose those large boulders into more achievable gravel-sized stories to help your team achieve focus and improve delivery times.

Posted in Agile Coaching, Agile Management, Iterative Development, Scrum Development, Scrum Methodology | 1 Comment

Who Really Needs Agile Training?

This post was originally published on ItemsOnTheLeft.com.

Little LeagueI have two young boys, both of whom play baseball. My wife and I are at the ballpark a lot. If you’ve got a ball player, you know how impossible it is to just be a bystander. There are so many games, they work so hard, and they only get so many chances to do something wonderful – it starts to get in your blood. You start wanting success as much as they do. You start coaching them in the car ride home, analyzing each swing, each pitch, each drop step in the outfield. You start to panic when they haven’t hit the ball for three games in a row.

The Matheny Manifesto

It doesn’t help that I live in St. Louis, a city whose common denominator is the St. Louis Cardinals. The Cardinals is one of the oldest and winningest teams in baseball history. They are currently managed by Mike Matheny, the youngest manager in the MLB. Matheny was hired just a few years ago, and he was able to take the team to the post season in each of his first two seasons, and to the World Series last year. Earlier in his career he was a catcher for the Cardinals, but his only management experience consisted of coaching a youth baseball team. During his tenure in little league, he established what is now referred to as the Matheny Manifesto, a lengthy dissertation on his coaching philosophy. It started as a letter to the parents of the team he coached, but it has become popular among little league teams. Coaches will often ask parents to read it at the opening of the season to remind them to keep their priorities in check.

A few highlights from the manifesto:

  • “I have found the biggest problem with youth sports has been the parents.”
  • “I believe that the biggest role of the parent is to be a silent source of encouragement.”
  •  “Our culture has lost respect for authority mostly because the kids hear the parents constantly complaining about the teachers and coaches of the child.”

If you have the time to read the entire seven page, 2700ish-word letter to the parents of his little league team, I highly recommend it. You’ll understand rather quickly who exactly he’s trying to coach. And it’s not the kids.

It’s These Parents That Need the Coaching, Not the Kids!

Organizations spend a lot of money, time, and energy reorganizing departments, implementing a new tool, or even adopting Agile in the hopes that such changes will improve the quality of the software they deliver, or perhaps make them deliver faster. These efforts are more often than not aimed at those that are actually doing the work. When I visit a client, I’m typically spending time with the developers, testers, and project managers. The thinking is that if they’re the ones undergoing the change, they’re the ones that should be trained.

But there’s a very important element of improving software delivery that isn’t being addressed in these training sessions: management. In the ball park, Matheny recognized that building a successful baseball team included training the parents. He saw that the parents need to learn how to be parents of little leaguers. In the world of software delivery, managers also need training – they need to learn how to be managers of Agile software developers.

 “I am completely fine with your son getting lessons from whomever you see fit. The only problem I will have is if your instructor is telling your son not to follow the plan of the team.”

We can provide Agile training to our teams until they are experts. But if we can’t provide their managers the skills they need to steer them within the Agile principles, what value is the training? Teams are being trained to self-organize, but we expect managers to just fit in to that model. Teams are being trained to favor face-to-face conversations, but managers are still holding on to the chain of command. How can Agile teams be successful with such an uneven training plan?

If we expect Agile training efforts to pay off, we have to train the managers how to manage Agile teams.

Training vs. Training

At work, we think of training as a one-time event. We consider ourselves proficient in a particular software program because we went to training. On the baseball field though, the concept of training is completely different. It’s repetition-based. It’s taking 100 grounders, or throwing 50 pitches, or repeating a pick-off play over and over and over. Agile management training should resemble baseball training, with a lot of situational role-playing and repetition.

A baseball player would never think he was proficient at baseball because he went to a one-time training event. And his skills would deteriorate if he left the game for an extended period of time. Likewise, Agile management training should be an ongoing effort.

The primary lesson of the Matheny Manifesto is that parents need to back off. The kids will improve at a faster rate if they aren’t constantly pressured by their parents. If the kids are given the freedom to make mistakes, they’ll learn faster. But this is a difficult pill to swallow for many parents, so Matheny spends as much effort training them as he does his kids. The parents had to be trained so his kids could be trained.

I suggest we train managers of software teams to take the same approach. Agile managers should be trained to back off, let their teams make mistakes, and give them the freedom to improve. It’s the only way to make the team training effective.

Sound off

What do you think? Managers, are you getting the training you need to manage your teams? Team members, do you feel your managers have the skills to allow you to be successful? Leave your comments below, or send me a note on Twitter at @johnkrewson.

Posted in Agile Adoption, Agile Coaching, Agile Management, Agile Teams, Agile Training, Uncategorized | 2 Comments

Pepperoni, Metrics and Software

Guest post from Don McGreal of Improving Enterprises

The disconnect between the delivery organization and the business is prevalent in the software industry. Somewhere along the line, the real vision behind our projects gets lost. We all know it.

Can better agile metrics help?

Let’s talk pizza.

You work at a growing pizza chain. You are part of their delivery organization. You and your colleagues are responsible for getting pizzas out the door and to the hungry customers. You have managers, drivers, phone operators, vendors, etc.

How do you know if you are being successful? What metrics will you measure your progress against?

I would like you to take a minute to think about this. Write the metrics down. I’ll wait…

agile-metrics-pizza-mcgreal

 

 

 

 

 

Did they look something like these?

 

 

 

 

 

 

Good. I thought so.

A perfectly reasonable set of metrics, right? If you care about improving your department, you should definitely track them.

Now, let’s switch roles. You are now part owner/operator of the pizza chain. I would like you to come up with another list of metrics that matter to you and your partners.

Write them down. Again, I’ll wait…

agile-metrics-mcgreal-2

 

 

 

 

 

Did they look like these?

 

 

 

 

 

 

 

 

 

Great! Nice work.

Now, are your 2 lists much different? I am sure there are a few overlaps (e.g., Customer Satisfaction, Costs, etc.) But I’m willing to bet that they are mostly very different from each other. Why is that? Is that even a bad thing?

Here are 3 things to consider:

1. EFFICIENCY

The delivery organization now has a set of shiny metrics they can work toward. The practices and processes they put in place will focus on moving these numbers. The assumption is that by improving these intermediate metrics, the business will benefit:

“Hey look, we spent all this time implementing these route efficiency algorithms so that we can save 30 seconds on each delivery.” You may reasonably assume that this will be good for the business, but it’s no guarantee and may even become more of a distraction. Popular practices are great, but they aren’t the end goal and we can’t lose sight of the business’ true needs. Otherwise you end up with a Cargo Cult mentality.

3. VISION

The more your people know and understand the true vision and goals of the organization/product, the better decisions they will make. Like it or not, assumptions and decisions will be made independently. You can minimize the negative impact of these decisions by educating your people on the true organizational drivers.

3. INCENTIVE

Your pizza shop has quarterly bonuses to hand out. What would you base them on? The delivery metrics or the owner metrics? Which ones have a greater potential for perversion? Any metric can be gamed, but you’ll notice that the more intermediate circumstantial metrics in the delivery department have bigger opportunity for abuse. This doesn’t just create unintended behaviors; it also reduces the transparency and, therefore, the usefulness of these metrics.

A few years ago, my wife and I went to dinner at a chain restaurant. Before leaving, we were presented with a customer satisfaction survey and told, “If we give all ‘excellent’ scores,” we would receive a free appetizer for our next visit. This was obviously not the way the business intended to use these surveys.

So what does this mean?

The delivery metrics aren’t without worth. They are very helpful, even essential, for guiding our more tactical practices. But we run into problems when they are used as false representations of value and set as achievement goals. If the business doesn’t establish the goals along with more direct value metrics, then the delivery organization will have no choice but to offer up their own.

Software

You have probably already done this, but can you now correlate these metrics with the ones on your software projects?

Which metrics are used by software delivery departments? Which ones by the business?

delivery-agie-business-metrics

*Learn more about Velocity, Code Coverage, Coupling, Cohesion, Code Complexity, and Lead & Cycle Time.

So how does your organization measure success? Are they spending too much time on the left-hand side? Are there opportunities to instead apply metrics that reflect true business outcomes? This concept of using direct rather than circumstantial evidence is known as Evidence Based Management (EBM). It is gaining traction in the technology field and has industry leaders like Ken Schwaber advocating for it.

With EBM, our pizza chain could evaluate the valuable outcomes to determine which parts of the delivery process contribute to them.

For example, if the chain had very large orders for 2 important customers come in at the same time, they may be inclined to wait until both orders are complete before sending out the driver. This would certainly improve delivery metrics (pizzas per trip, miles per delivery, fuel used, orders per driver), but may not be the best move for the business overall.

If instead, everyone involved was focused on EBM, they would be more concerned with the valuable outcomes that have a more direct impact on the organization (customer satisfaction, lead time, repeat customers). This may compel them to create a practice of sending 2 drivers if the orders are big enough.

This disconnect between the delivery organization and the business is prevalent in the software industry. Somewhere along the lines, the real vision behind our projects gets lost.

Challenging our managers, product owners and development teams to identify and promote metrics related to real outcomes is key to bridging that gap. This can promote true agility beyond IT departments and give organizations a real competitive advantage.

—————–

Don McGreal is VP of Learning Solutions at Improving Enterprises and is co-founder of TastyCupcakes.org, a comprehensive collection of games and exercises for accelerating the adoption of agile principles. Improving Enterprises is a leading software development company that offers advanced technology consulting and training across our 5 locations in Texas, Ohio, and Canada.

Posted in Agile Methodologies, Agile Metrics | 4 Comments

Why Affinity Estimation?

Guest post by Max Woolf, software developer at Box UK

Software development practices are improving every hour of every day. Open source software continues to grow exponentially, with companies like GitHub posting explosive growth figures over the past year. Full-stack web frameworks make development quicker and encourage agility more than ever before. However, one aspect of software development remains a thorny subject. Where we still have a lot of work to do: Estimation. With software development being a primarily creative endeavor, why do we put such an emphasis on estimation? We wouldn’t ask a painter or composer to give us an exact completion date because we know it’s impossible! So how is this any different?

Estimation is just part of the game now:  clients expect estimates and we need to be able to provide them to remain competitive. So, why don’t we do it as best we can? Being practitioners of agile methodologies, we’re already past giving estimates in days and hours, but even story-point estimation can be tricky for all but the most experienced teams. We need a better solution and I believe affinity estimation is the next step in improving software estimation for us all.

So, what is affinity estimation?

Affinity estimation is just a technique by which story points are assigned to user stories. It’s not an agile methodology like Scrum, XP or Kanban but it can help improve the planning and estimation elements of agile methodologies like these. It’s also not for everybody! If you belong to an established Scrum team with a steady velocity and high productivity, then maybe changing your estimation technique isn’t a great idea. However, the technique can offer significant benefits for many organizations.

Take a typical Scrum team. Estimation could mean anything from playing planning poker to just sitting around a table and coming to a consensus as a team about the effort required to complete a particular user story. You may find that this creates massive inconsistencies and it takes far too long to nail down a steady velocity since the estimation session takes too many indirect factors into account; things like the mood of the team or subconscious biases can play an important, yet often overlooked, role in user story estimation.

Down to business. There are 3 main parts to a successful affinity estimation session:

  1. Backlog grooming and prioritization
  2. Relative estimation (sizing)
  3. Story-point grouping

Step 1: Backlog grooming and prioritization

As per regular Scrum rules, the product owner needs to prioritize the backlog prior to the estimation meeting.

Step 2: Relative estimation

This is the main task in affinity estimation. Firstly, each user story is written down on a card and placed in a pile. Each member of the development team then takes turns to place a card in a line on the table or adjust the position of a card already on the table.  At the end of this step, there should be a continuous line of user stories from those requiring least effort on the left and those requiring most effort on the right. At this stage, it makes no difference how much more difficult the user stories are from each other. The important thing is that the stories are ordered relative to each other.

affinity-estimation

Step 3: Story-point grouping

We can now happily say that the user stories on the left are easier than those on the right. Therefore, it’s highly unlikely that the user stories on the left will be 21 story points or the stories on the right will be 1 story point. We also know that if the easier story is 3 points, anything to the right of it must be equal to, or greater than, 3 story points. With this information we can then divide the cards into similarly sized groups and assign a story-point value that can be applied across all user stories in that group.

Does it work?

We certainly think so. Affinity estimation doesn’t solve the problem of assigning story points to user stories, but it does speed up the process considerably. At Box UK, our sprint planning and estimation sessions are much quicker than they were previously with this newly added structure. Our estimation sessions typically take 15-30 minutes less than they did before, and planning sessions can sometimes last under 20 minutes if the backlog has been ordered and all the user stories already estimated.

To speed up the process even further, Box UK has created a tool means we didn’t have to write user stories out on cards and can use a computer instead. It’s in beta at the moment, but we’d love to hear your feedback; take a look at http://estimation.boxuk.com.

 

Posted in Agile Methodologies, Agile Teams, Agile Velocity | 1 Comment

Agile Mind-sets: The Power of an Analogy

Guest post by Fred Pernet and Roly Stimson of Emergn

Never underestimate the power of an analogy. Scientists increasingly think it is central to pretty much all thought, but particularly innovative thinking, where we are moving into new conceptual landscapes and need familiar points of reference to find our way (oops – out popped an analogy, right on queue!).

That is how we ended up with gravity being thought of as a form of “attraction,” and sub-atomic particles having attributes such as “spin” and “color”(even though they definitely don’t really have color and probably don’t really have spin).

Analogy is also very useful in helping to change our mind-sets, and keeping them changed, when it navigating through relatively new conceptual territory, such as lean and agile development.

So here is one of my favorite extended metaphors for comparing agile mind-sets and behavior with more traditional development approaches.

Imagine you are super-rich. (If you are not, I’m sure you have practiced imagining that you are!). Your absolute favorite go-to car is your Bentley Continental GT. You know it, and you love it (for obvious reasons).

To relieve the unending sameness of your fabulously leisurely lifestyle, you decide to go on a road trip. To Tibet!

So, do you take your beloved and trusted Bentley Continental, or do you take your slightly less-cherished Toyota Hilux instead (for non petrol-heads: a 4×4, very robust, but somewhat utilitarian)?

It’s a question I like to pose to my agile training classes. Opinion usually splits down the middle, so we start to weigh up the likely outcomes as we embark upon our imaginary journey.

Down to Dover, the Bentley brigade are feeling happiest with their choice. The case is similar as we cruise through Europe.

But pretty soon we hit some strategic decisions. Do we go around the Black Sea or through Turkey? We might have to leave the decision late, depending on the current political stability of various countries. The GT might still be doing OK, but the road conditions are getting significantly more variable.

Anyone who has undertaken long treks like this will know all about Murphy’s Law – “If something can go wrong, it will.” It’s no mystery really; on a long trip like this, through territory we have not charted before, it is a simple fact –  the chances are certain that something will go wrong somewhere along the lines. Burst tires, potholes, a broken axle, …. the possibilities are endless. Can we get our Bentley serviced in Turkmenistan? And what are the chances of it being carjacked and us being kidnapped along with it?

And as we approach our destination, what do we find? Much steepness. Ice. Snow. And how’s our Bentley doing now? It’s clearly out of the race.

The 4×4 is victorious because of its versatility – it enables us to respond to whatever may be thrown at us. And so, safe in the knowledge that “stuff” will happen, it is the right strategic option for a journey into the relative unknown.

So how does this compare with product development in general, and software development in particular? Have you ever developed this software application to solve this problem with these technologies before? No. If you had, you’d be acquiring or reusing the solution, not developing a new one.

So what kind of team do you want be to as you undertake such a journey? One that is adaptable and can respond to the highly predicable likelihood that somewhere along the line, “events” will cause us to have to rethink our approach? Or one that is super-reliable if told exactly what to do and how to do it at all times, but completely at a loss when reality starts to diverge from our carefully laid plans?

Of course, if our destination is our favorite countryside hotel in the Cotswolds, it is probably a different matter. A well-known route. Smooth tarmac all the way. A 4×4 will be neither preferable nor faster on such a journey (and so the simplistic “agile always means faster” gets myth-busted).

And finally, just to suggest briefly some possible extensions of the analogy: what about planning our journey? Not much is needed for our trip to the Cotswolds. Jump into the car, set the nav, and away!

The Tibet trip obviously needs more planning (another common agile myth busted – agile definitely doesn’t mean not planning ahead!). But, if we plan the whole trip in meticulous detail, the chances of that plan being executed is close to zero. Instead, we might plan as far as Vienna, and beyond that have a rough idea of our route options, but plan to re-plan from there based on current information, and probably only plan the next leg of the journey in any detail.

The moral of the story? As a development team, think “4×4” – adaptable, robust in the face of adversity, ready for anything, and always planning to re-plan.

Tibet had better be worth it!

Posted in Agile Benefits, Agile Methodologies, Agile Teams, Lean, Lean Software Development | Leave a comment

Be an Agile Scholar

“If you do that, you’re NOT Funky Stenciled No Trespassing Sign IsolatedThe trouble brewing in my mind, “When did framework xenophobia become the norm?”

Somewhere, somehow, I think many of us lost the intent behind these frameworks. When did it become more important for your sprint planning meeting to last 4 hours, no more no less vs. “Is the business and development team communicating and collaborating?”

To the retrospective question, if a mature team has inspected and adapted their process and decided to conduct retrospectives more frequently during their sprint, vs. a single ceremony at the end, is this bad? Wouldn’t it still meet the definition of Scrum?

One could argue yes, but why are we arguing at all? We should be learning from that team to see if it is something we can do on our own teams (OK, ‘borrow’ from their practices).

I am not going to attack Scrum. It works very well when a team understands the concepts behind the framework. What scares me is the increase in people that equate being agile to implementing Scrum. It feels as if many of us have lost sight of the purpose of these frameworks: deliver working software!

2014 might be the time to stem the tide of “Scrum scholars” and encourage more people to be “Manifesto scholars”.

After all, the purpose of the popular (or not so popular) agile frameworks is to simply be vehicles bringing the Agile Manifesto and its principles to life.

I cringe when I hear that people are being judged or ‘graded’ for their performance review by how rigorously they follow the ceremonies of a particular framework. By and large, it is not simply good enough to hold the ceremony for the sake of the ceremony. The team needs to understand its intent and extract value. Otherwise it is just another meeting people come to dread.

USA Constitution ParchmentRather than grading facilitators or scrum masters on simply holding ceremonies, why not grade them on their understanding of WHY they hold it? Can they articulate the value it is supposed to bring, and the actual value their team gets from it? Do they understand how that ceremony gets them early and continuously deliver valuable software?

We are well into this new year, but maybe it is not too late to start focusing on the manifesto.

By adhering more to the foundational principles, vs. strict adherence to a framework with blind optimism, maybe we will produce less ceremony check marks and more working software.

 

Posted in Agile Adoption, Agile Benefits, Agile Coaching, Agile Management, Agile Methodologies, Agile Teams, Agile Training, Enterprise Agile, Extreme Programming, Kanban, Scaling Agile, Scrum Development, Scrum Methodology | 3 Comments

The Agile Coach on Focus

To me, nothing is more frustrating than context switching (i.e. multi-tasking). It takes away from our ability to focus.

FocusAs a result we’re far less productive. We often produce more bugs, and are generally more stressed out.

You may have gone through this exercise (or one like it) in an Agile Bootcamp or Scrum Course; it’s called ‘Multi-tasking is worse than a lie’. Here’s how it goes…

Get a piece of paper and write the sentence: Multitasking is worse than a lie

Every letter you write, you should immediately write a number just below it, starting with 1 and going through to the number 27 as you reach the last letter in the sentence.  So you write “M” and then 1, you write “u” and the below it 2 and so forth.  You keep this up until last letter of the sentence and you time yourself.

Now try writing the sentence in full followed by the numbers 1 to 27 in full. Again, time yourself.

What I’ve found over and over again is that, on average, it takes just a little more than half the time in the second instance. We’re still doing the same amount of work, mind you.

Now think about how simple this exercise was. And about how complex the development of software is. And compound that by the number of projects and tasks you may be shuffling.

So the point is made, and everybody agrees that we need more focus and less context switching. And then we go back to our real jobs and get pulled in 10 different directions at once. It’s madness!

So why aren’t many of us willing to do something about it?

I spoke in one of my previous blog posts, ‘The Agile Coach on Courage’ about how standing up and telling your boss that you’re overwhelmed is hard, but necessary. It takes guts. Sometimes you’re being asked to be a member of several project teams at once. Other times, you’re being yanked off an active project (with little to no notice) to work on a pet project for a C-level executive. Telling your boss the consequences of such actions is hard to do, but necessary. And if they’re a good boss, they’ll actively listen to you, empathize, and try to remove any impediments that stand in the way of you getting work done productively and of the highest quality. True servant leadership.

But in order for them to help, you must let them know that this is disrupting not only your productivity, but the rhythm of the team as well.

Scrum Masters, listen up because this is on you as well. One of your major functions is to protect the team. So educate the Departmental Managers on the evils of context switching and multi-tasking. Press the issue tactfully. And if you don’t have enough people to get the work done, raise it as an impediment. Make it visible. Let it drive a discussion around the scope of the Product Backlog, the Release Backlog, or dates. Our velocity is what it is. You want to increase it? Adding more team members oftentimes won’t do it. In fact, it can even decrease velocity in the short term. So be careful of this tactic if you’re running up against a tight deadline. Let it be known that our team works at a sustainable pace. Yes, we can work longer hours from time to time when it’s really needed, but don’t let it become the norm and burn folks out. One of the telltale signs of this occuring is a spike in the number of bugs introduced, a simple metric to keep visible and discuss in your team retrospectives.

I’d like to hear your thoughts on this topic. How do you deal with context switching/multi-tasking?

Posted in Agile Adoption, Agile Management, Agile Project Management, Agile Teams | 1 Comment