SAFe Train Engineers: Metrics - Activity Accounting

Copyright: cthoman - 123RF Stock Photo

As a Scaled Agile Framework RTE (Release Train Engineer), one of your primary goals/responsibilities is to measure and track the improvement of the teams and the train.  One of the ways to do this is through Activity Accounting.  Essentially, this is an assessment from product developers stating the percentage of time they spend on each measurable activity (the important ones).  We then want to help the teams turn these numbers from many of the non-value add activities towards the direct value add, like innovation and planning

First, to measure these things.  Work with the teams to figure out what makes sense, but an example to maybe start with is:

• Defect fixing
• Code Integration
• Planning
• Branching/Merging
• Manual Testing
• Creating/maintaining automated tests
• Innovation
• Other?

Copyright: 123RF Stock Photo

Have your teams determine how to measure their selected items from a % of total time spent, for example, Integration might be 10%, manual testing 30% and automated test creation might be 15%, etc.  Don’t worry about actual hours, just percentages.  Then, assess that data in the I&A workshops in your planning events.  Which ones stick out as issues?  Which ones would add the most benefit if improved upon (usually reduced)?  How can we shift from non-value add (branching, defect fixing, etc) to value add (planning, innovation, etc)?  Share these numbers, goals, and plans with your leadership to show them where you are now (transparency), and what your targets are and your plan to get there.  Incorporate these improvement efforts into your planning event as objectives and help the business owners understand the business value of these items.

One other thing, be fairly aggressive on these goals.  For example, improving automated testing by 1% is pretty weak, try for a higher number that seems challenging but still reachable.  If you don’t make that number, that’s ok, you will learn much more about what is keeping you from those targets, and these newly discovered impediments can be addressed as new objectives in the next planning event.

If this sounds like a lot of work, it is.  But it’s well worth it.  If you say that you don’t have time to add this to your plate, look closely at what’s on your plate.  This measurement practice is the protein and vegetables you need, a lot of the other stuff is just empty carbs and should be prioritized out or delegated to someone else.  Your true value as an RTE is in helping the train improve, using Activity Accounting is one significant way to do so.

(Much credit for these concepts go to Humble, Molesky and O’Reilly in their excellent book “Lean Enterprise”.  I recommend every train engineer have a well-read copy at hand)

Just what is an Agile coach?

Having labeled myself as a coach for the last 10+ years, and having trained other coaches, I’m often asked about just what is an Agile Coach?  Just like in many other industries that have no true certification or accreditation, we see people claiming the title that maybe should not, and others that are coaches without even knowing it.  I thought I’d share my thoughts on what I believe the attributes of a true coach is, and why it’s important to understand these attributes.

Definition

Merriam-Webster defines a coach like this:

  

Merriam-Webster aside, the Lean Agile movement is all about self-organizing teams, de-emphasizing meritocracy and Taylorist style management, and teams and organizations learning and adapting as they go.  So how does a traditional term like Coach, that implies some level of direction and decision making, apply to how we help teams and orgs succeed?  It’s simple, really, we do both.  A true coach will create an environment of self-learning and growth, combined with the safety of just enough guardrails to enhance the chance for success. 

However, there are times that a coach needs to provide strong guidance and direction to help avoid as many of the potential mistakes as possible.  This doesn’t mean shielding the group from experimenting or trying new things, but it does mean to start the group on the best footing possible.  I heard from one of my favorite agile champions several times “we didn’t bring you in here to tell us what we are doing right, we want you to tell us what we are doing wrong”.  There are many occurrences when a coach has to establish guidelines, guardrails, or guide posts to help direct the groups.  If your family is running along a mountain top and are heading towards a cliff you might say “are you sure you want to run that direction?” but there comes a time where you will physically stand in front of them to prevent them from going off the cliff.  The same is true for a coach; we want to help the groups learn, oftentimes from their own mistakes, but there can come a time where you have to stand up and say “no, don’t do that” and help them understand both the dangers they face as well as some alternatives they could try.

Over the years I have developed a set of attributes that I think are critical to have as a coach.  Some have to be there from the start, others can be developed along the journey.

Empathy

Your clients are typically coming from a different perspective than you, and it is critical that you can   When I coach a mid-level manager on standing up to a tyrannical manager that is blocking progress, or a command and control HR department that wants control and stability, I have to remember to view the situation from the eyes of the manager I am working with.  Often times my first reaction is to say “What’s the worst that can happen, they could fire you?”  But then I remind myself that the manager may have built a career in a difficult environment, has just bought a house near the office, or any other number of reasons that they may have the self-preservation instinct kicking in to block them from doing what they know they should do.  Working alongside them, observing (without being observed) in as many of their interactions with the problem situation, and trying to really understand the problem from their perspective is a critical aspect of a good coach, and one I continue to work on myself. 

put yourself in their shoes (to a point) to understand how best to help them.

Courage

My definition of courage is not being fearless, but rather facing a situation in the presence of fear.  As a consultant you are often walking a thin line between continuing on with the client and going to that next engagement, but that should have limited impact on how you face a difficult situations.  As an internal coach you may feel that you have job security and a home for the foreseeable future, but you have to set this aside in favor of what’s right for the company.  Courage is about knowing what’s right and fighting for it, despite the consequences. 

Passion

Monotone just doesn’t cut it.  Lethargy is a buzz kill.  Indifference is the enemy.  Passion in helping others see success, in displaying excitement for the potential, in giving others a kick start from your energy level, all of these are vital to a coach.  This does not mean you carry pom pom’s around and try to get the crowd to do ‘the wave’, but it does mean that you carry yourself with a certain level of energy that others can see.  It means showing your excitement for what they are doing.  It also sometimes (many times) means bringing the energy level up by your example and sometimes by being a part-time cheerleader.

But, passion is more than that.  It is that deep seated desire to see others succeed, in knowing that what you are doing will help them achieve great things, and taking pride in their accomplishments.  It is displaying that level of caring that goes way beyond a billable rate or bi-weekly paycheck.  It truly is demonstrating in everything you do that your true desire is for their success.

Resiliency

Coaching teams is not all fun and games, and can be quite frustrating at times.  When you see the level they could achieve, and yet all the times that they continue to stumble, it can take a lot of wind out of your sails.  A true coach must have a dogged sense of determination and the ability to look past the short term struggles.   A continued outlook of “well, that didn’t work.  What did we learn and what are we trying next?” is vital, and must be clearly visible to the groups you work with.  You must have the ability to always try to draw the positives out of a situation and use what was learned to apply to the next effort.  Yes, some situations can be impossible, there are teams and groups that just don’t want to move forward, but up until that point is reached you need to have the “Never give up” attitude.

Knowing When to Back Away

As I just said, there are times when you need to cut your losses and move on, at least for the interim.  Whether you are a consultant or an internal FTE coach, you will face situations where your customer is not ready to change, not ready to transform.  When to back away is never an easy decision; many clients I have worked with that I initially thought were a lost cause have turned out to be some of the most successful.  But often times an organization needs to struggle more before they can find that sense of urgency that is so critical, and the commitment to change how they think and act.

When working with larger organizations this can open up opportunities to work with other groups that are ready to commit, and then use those groups as ‘bright spots’ for the more reluctant group.  There does come a time when you need to say to a team, organization, or group “I’ll be back when you are ready”.   Good coaches are hard to find, and as such we need to help make sure we are working on the most valuable effort that we can, the one that will produce the most value for the business overall.  

Humility

My favorite phrase about how a good coach will act is “Be the Guide on the Side, and not the Sage on the Stage”.   A good coach will use every viable opportunity to create a learning opportunity and a chance for growth, rather than be seen as the ‘Expert’ or the puppet master pulling the strings.  A true sense of humility and encouraging the teams to take the credit for their success is critical.  I have been called many terms of endearment or ap   A real coach will step back from the limelight and let the group revel in their success and achievements (and then help them realize that they still have a long way to go).  There are many times that at the end of a very successful workshop, training, or other event where the group has made a major breakthrough, I will sit to the side or in a corner and let the team celebrate.  After all, it’s their victory, not mine!  We have to learn how to take our metrics, growth opportunities, and career satisfaction directly from the success of others.

preciation by teams and orgs that I have helped, and that always makes me uncomfortable because I know without the hard work and commitment of the team I would not have accomplished anything.

Quick Wit

Sometimes defined as ‘smart ass’.  There are many times that you can diffuse a tough situation, calm nerves, or just take the edge off a room with a well-placed one liner, joke, or funny comment that can get a chuckle and bring everyone back to reality.   It’s called a ‘sense’ of humor though because we have to have the right timing and content to make it work.  The easy ones are the self-deprecating ones, “if only you guys had a decent coach, you would have seen that issue much earlier” or the like.  Obviously, stay away from anything viewed as a personal attack, but I don’t avoid the cultural or gender issues that many times crop up or are under the surface.  Throwing in a quick quip around the problem can help everyone relax and realize that they need to discuss this openly, especially when it’s a sensitive subject.   We are trying to create an environment of transparency, honesty, and collaboration, we can’t do that without addressing the tough challenges, and very often a little humor can help us get to a place where we can effectively address the issue.

Transparency and Honesty

I put these together because they are hard to separate; how can you be honest without being transparent?  And true transparency is based on honesty as we expose ourselves to the realities of our thoughts, goals, ambitions, etc.   Above all, a coach needs to exemplify the character attributes we are trying to build in our clients, otherwise we just appear as a phony.  We have to be willing to expose our mistakes and not try to appear as perfect.

Hunger to Learn

As in many other things in life, product development is really about knowledge gained.  Acknowledging that we don’t know everything (if we did, we wouldn’t need small batch sizes), and having a never-ending thirst to learn more is critical to be a successful coach.  There is a wealth of knowledge out there in books, blogs, websites, etc. from people that are on the same learning journey but perhaps are farther along.  We need to take advantage of these pieces of knowledge already out there, and add to them with our own experiences and nuggets of wisdom gained.  By making this thirst for knowledge very apparent we can instill the same thirst in our clients, letting them know that it’s ok to admit that you don’t know everything.  

All of these attributes that (I hope) we agree are vitally important to a good lean/agile coach, but does that still sound like the Merriam-Webster definition?  I think it still does in many ways, but the most important difference to me is the approach of “take a back seat as soon as you can”.  Yes, we are really trying to coach ourselves out of a job, since our true success is only when our clients no longer need us.  To me, using, exposing and growing the above attributes is one critical part to attaining this end goal.

Forming a highly functional Scrum team – Part One

There seems to be a lot of misconception in the agile community as to what ‘self-organizing’ means.  When we talk about teams self-organizing, we are not talking about a group of 50 people in a room deciding how to make up 6-8 scrum teams.  Yes, that can be done, and it can be effective, but the real gist of self-organizing means to allow the already formed team to determine how to get the work done.  Self-organizing means giving the team the autonomy to determine how to complete the work, but often times the teams need to be formed up first.  Although there are many successful case studies of ‘build a team on the fly’ approaches, there is also a lot to be said for forming these teams with a plan.

I spoke at a conference that Esther Derby was also speaking at, and was privileged to hear her talk on team formation.  She made a statement that took me awhile to process when she said that “60% of the success of an agile team lies in the initial formation of the team”, meaning there is a lot to be said for building the team right to start with.  This was at a time that I was really on the self-organizing bandwagon and so I had to really think through this one.  As I did, however, I realized how right she was.  Building the right team from the start, with the right personalities, drive and attitude, and the right mix of skill sets was absolutely critical to the successful teams I have worked with.  Many (most? all?) of the teams I have worked with that were struggling were seeing issues because of their initial formation.  A team of all extroverts with strong opinions will just clash and fight against the tide, while a team of all introverts will be too passive and just flow with the tide.   A team strong in development but weak in testing practices will struggle with quality, and so on.

So, how exactly do you form the A team for an agile environment?  This is more art form than science, but there are steps that can be taken to increase the chance of success.   These steps include skills analysis, personality assessment, and aligning common goals and interests (amongst the other soft skills needed). 

Personality Assessment

Paramount to building a successful team is to understand what type of team mentality you are looking for.  Do you need a hard charging, driven type of team that won’t accept failure (R&D, Skunkworks, etc) or do you need a team that has a high degree of compassion for the user and always keeps the users’ needs first (Support teams) ?  Understanding what type of team you want to end up with is critical; set up your own acceptance criteria for the team so that you have a clear definition of what ‘done’ looks for the team formation.  Compassion for the user, a drive to accomplish the ultra-cool, and a comfort level with a steady, rhythmic cadence are great team personalities to cultivate

The best scrum teams tend to form a personality all their own, based on the sum of the parts, and you can set the team on the path you want by mixing the right blend of personalities on the team.  Because very few team members will have each of the desired qualities, look for members that bring one or more of the desired qualities and show an open attitude towards the others.  Use scenario based questions that will help bring out the candidate’s personality traits you are looking for.  For example, if you are looking for the customer focused personality, ask a question similar to this.  “Imagine you are asked to staff the support desk for a few days, and a customer calls in that really doesn’t understand our product.  How would you help this customer?”.  Based on the answer, try to put the candidate in a difficult situation by stating “yes, but let’s say the option you just described is shot down by your supervisor, or is against company policy, now what?”  Gauging the depth to which the candidate will go towards helping the customer to a solution that works for them and the company is a great indicator as to how deeply they will care about the features being built by the team.

Skills

One of the tenants of the Scrum framework is to have all the needed skills to complete the work on the team so that there are no external dependencies (and other reasons).    But what’s a good mix, and how to identify these team members?  First, don’t go for all superstar team members, the ones that can do anything and everything.  They usually don’t exist and, even if they do, are usually not what you really need.  Look for candidates that have demonstrated a high level of aptitude in learning new technologies rather than the one that has remained an expert in the same technology for many years.  In today’s business world, skill sets need to not only improve, but adapt to the latest and greatest, as well as have a knack for understanding what new technologies are worth pursuing.

Just like with the Personality aspect, make sure you set out a goal for what type of skill sets you want on the team.  If you need to have a high level of quality (medical devices comes to mind) over technical aggressiveness, than purposely build that team skill with a high level of quality driven candidates.  If you are building a fast paced team to research and prototype new products you will obviously want to go towards the candidates that can work within a “good enough” quality approach.  Most teams will be in an environment where quality and speed are equally as important, in which case you are looking to blend candidates of both mindsets together.

If you are building more towards the quality side you can ask questions such as this.  “We are ready to push the Deploy button but have found a defect in our code that can affect the user.  What would you do?”  If the candidate comes back with a ‘”Stop the presses and fix the bug”

Intangibles

Team work is everything in agile environments, and mixing in the right intangibles is so critical to taking a collection of individuals and helping them turn into a team.  I just finished watching “The Internship” (for the second time, good movie), where the main cha racters are accepted into the summer internship program at Google.  The whole movie is based on interns joining a team and having to succeed or fail as a team, the winning team will be hired on full time.  Sure, it’s a movie, and may not be all that close to reality, but I really like how they portrayed looking for ‘that Googliness’ in each potential candidate. 

Looking for these intangibles is, in most cases, the most difficult and the most important part of building a successful team.  Determine what intangibles are important to you by wide scope categories (since most intangibles found in an individual are usually unique) and devise ways that help you see those qualities.  The most important thing to remember is that the search for these intangibles is just as important as any personality or skills assessment you may apply to each potential team member.

What’s Next?

Just like building successful Scrum teams is an ongoing process, this blog will be a series of entries, each dealing with the next step in this journey.  Look for the next post that discusses pulling the team together, aka, Day One of the new team.

Shared roles in Scrum

I am working with two teams from different clients right now that are both struggling with the concept of swarming and cross-discipline work.  Each of these teams have team members that are experts in their own area, but run the spectrum from not comfortable to just plain don’t understand the other technologies or practices that the team needs to accomplish the work.  The result is that both teams are struggling to get stories done because of the lack of ability to focus on just one or two stories at a time; since many team members would ‘have nothing to do’ and others are overworked.  One of the primary focuses that we have for improvement is to learn to swarm on stories and begin the cross-discipline training.

It seems that the general philosophy in agile coaching today is that every member on a scrum team should be able to do anything needed to complete the feature.  I disagree with that hard and fast interpretation, and the Scrum Guide also does not support this concept.  Summarized, the guide states that all disciplines needed to complete the work need to be on the same team, not that all team members need to do the same work.  (Scrum Guide, pg 4 ‘The Scrum Team’).  Self-organizing means the team figures out how best to get the work done, which includes who best to do each portion.  However, the guide does stress that “The team model in Scrum is designed to optimize flexibility, creativity, and  productivity”.

I think the statement that really started the “everybody does everything” mentality was this:

·         Scrum recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person; there are no exceptions to this rule;

But then those same people skipped over this:

·         Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.

I was at a conference a couple months back and heard Jeff Patton give an analogy that I plan on re-using in the future to help with this misconception. Essentially, think of your scrum team as a football team. (North American Football for you euro’s out there). In football, you have specialized skill sets that are pretty ingrained; for example an offensive lineman

is good at his job because of his specific physical and mental attributes, which are very different from a wide receiver's. However, on a given play, each of the 11 players on the field knows not only their role, but the other player’s roles as well, and could perform them if needed. A wide receiver can stay in and block, but they are not as good at blocking as a lineman or tight end.  A lineman can go out for a pass, but they are not as fast or as good at catching a pass as a receiver.

    (I challenge you to remember a time that you saw a 320 pound lineman streaking down the sidelines after making a fingertip catch?)  The point being that each player knows their own role innately, but as needed they can jump into other roles as appropriate to move the team forward.  However, when they jump in to those areas there will be a degradation (usually slight) in efficiency.  That loss of efficiency is more than made up for by the elimination of the queue that would otherwise form at the other team member’s feet. 

Applying this to a Scrum team, the reality is that each member has their specific skill set.  I cannot take a software developer that is really good at their craft, and move them into testing and expect them to be just as good as a well-trained experienced software tester, nor vice versa.  Each of those roles takes years to develop the specific skill sets needed to be an expert in that area.  I can, however, expect them to know each other’s roles well and be able to jump in to any role as the team needs them to so that the work can be completed.  If I need the wide receiver to block, he/she should not only be willing and eager, but understand enough of the technique to be successful.

This does not mean that there are no more experts.  Through pairing and other practices you are going to help share understanding and skills about using the testing and development tools and how to function within them, but it would take years of pairing to share each and every experience that has made each team member valuable in their own expertise.  (Having been a developer for multiple decades I know this first hand).  Many (most) developers or testers have gone into their field of expertise because that is what they want to do; forcing them all to be a homogenous pile of goo that can ‘do anything’ is not practical. 

The reason we as coaches teach and preach about cross functional teams and ‘everybody doing everything’ is to avoid the major downfalls of mini-waterfall (those dreaded queues again) and to increase collaboration and shared ownership.  Queues are what slows down a team because of the inherent wait states built into most (all) queues.  (Google queue theory or read Rienertsens excellent book “Principles of Product Development Flow”).   The delays built into queues are one of several key factors that slow down waterfall development and make it inappropriate for most software projects.

Collaboration is key to any agile team’s success, but making the blanket statement that no one can be a developer or a tester (having a primary skill set) is short sighted.  The tricky balance is building the collaboration while still allowing the efficient part of each team member doing what they are best at.  The best practices I have found, and the ones I plan on introducing with my current team, is to break the work up into small enough chunks, and keep the focus on only a story or two at a time within the sprint.  This tends to force the right balance of “that’s my skill so I’ll take that” with “I have nothing else to do in my skill area, so I’ll jump in to this other area to get this story done” mentality.  Back to the football analogy, I’m going to ask the team to run one play at a time, let them focus on that play and allow them to do what they are best at, but if the team needs the wide receiver to throw a pass to the lineman to score, then so be it.  But that offensive lineman is still an offensive lineman, and is needed to make a true team.

Casual Friday

It’s Friday, and my current client observes ‘Casual Fridays’ for a relaxed dress code (normally Business dress code).  It’s amazing to me to see the lack of productivity on Fridays due to everyone wearing jeans instead of shirt/tie or skirts/dresses.  The drop off in efficiency is just horrible.  And yes, I’m being extremely sarcastic.  What I do see is the same (or possibly more) work accomplished, the same level of professionalism, and the same level of drive to do something good for the company.  If the drive to make the company successful is not there with jeans on, it won’t be there any more with a shirt and a tie in place.

So, what does this have to do with agile, since this is an agile blog spot?  A Lot.  To me, dress codes, KPI ratings, manager performance reviews, and all the other trappings of the corporate lifestyle are one of the major factors inhibiting the agile movement really delivering on its promises across the spectrum.  Let’s take one of the agile principles and see what effect these artificial corporate practices have on agility.
“Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done”.

Dress codes are a holdover from a bygone era where how you dressed reflected how high up the ladder you were, and you had to dress appropriately to climb the next rung.  Many of the old school corporate executives still struggle with trusting the employees to ‘get the job done’, and they mask that lack of trust with an enforced dress code.  “If they are dressing appropriately, then I can assume they are acting appropriately”.  If only it were that easy.  This is something that, as an agile coach, I struggle with daily.  Yes, trust must be earned, but it must also be available.

My wife interviewed with a company back in the 1990’s and during the interview she asked about the dress code.  They responded “we prefer you come to work dressed”.  That was it.  That company was far more focused on hiring the right people and trusting them to do the job than worrying about the dress code.  I do understand that there needs to be some sort of standard upheld, and some companies do actually have customers coming in house that require some sort of dress code, but the point being that the emphasis is far too often on gaining the appearance of trust, rather than establishing an environment that fosters trust and commitment. 

People are not motivated by dress codes, performance reviews, or all of the other artificial trappings we put on it.  They are motivated by the intangibles, by the opportunity to do something difficult and having the environment where they can succeed.  In his book “Drive: The Surprising Truth About What Motivates Us”, Daniel H. Pink talks about experiments that have proved that pay, status, and other simple rewards are not what drives us.  The opportunity to challenge ourselves, the chance to stretch out and try something that we have not done yet, the ability to achieve something really cool, that’s what truly motivates us.  Once corporations understand this and focus more on providing these environments, the better off they will be.  There are a few companies you may have heard of that learned that early on, with names like Google, Apple and Amazon.

BTW, that company my wife interviewed for?  She got the position, and it was one of her favorite jobs of all time because their corporate culture was accurately captured in their simple response on the dress code.

It’s like kissing your sister

Why we should always strive to complete stories and tasks in the committed sprint

One of the most common missing attributes of teams struggling to adopt agile practices, particularly in a Scrum framework implementation, is the dedication to complete what was committed to.  Especially when coming from a waterfall background, where the exception is to complete on time (as per that glorious project task tracking sheet) and the norm is to have tasks slide.  And slide.  And slide.  Many of us have been conditioned to believe that this is ok because:

• “the original date was not realistic anyway”
• “The task grew to more than I expected”
• And the all-purpose “but I had to wait for this other thing to get completed”

Agile, and Scrum in particular, is very much about making us predictable.  Moving stories and tasks from one sprint to another (and another, and another) should be like kissing your sister; you will do just about anything to avoid having to do it.  (I grew up with 4 brothers so I can’t say for sure, but I think you get the point).

We have made a commitment to complete a set of work so that we can provide an agreed upon value to the business; our predictability is being counted upon to maintain the cadence of Scrum, and to build the trust from the organization that we will complete what we set out to do.

How do we become predictable?  How do we create a pattern of meeting these commitments?  It’s not by padding our estimates; that will make us predictable in a very bad way.  It’s not by overworking and going down the ‘death march’ path; that’s not sustainable.  And it’s definitely not by laying blame elsewhere; agile is all about personal accountability, team commitments and transparency.   We become predictable and create this reputation for meeting commitments by breaking things down appropriately, maintaining the proper level of communication, and by having a clear view of what done looks like.

How to avoid carrying stories from sprint to sprint

Humans are terrible at predicting very far out into the future.  When we try to predict how long something will take, the bigger the effort the worse we are at predicting the completion time.  When we invest time in making that long range prediction more accurate, we only succeed in extending the date out further; hence making the prediction even worse.

Break it dowm

When we break things into smaller chunks we not only can predict with more accuracy how long it will take, we also gain a ton of knowledge about what that value is and how to provide it.

In Donald G. Rienertsen’s excellent book “Principles of Product Development Flow” he illustrates this fact with the 6^th and 7^th principles of Product Development Variability.  In the 6^th principle he describes how forecasting becomes easier at shorter time-horizons as we are able to better predict the size and scope and also increase the speed of development (through less uncertainty, amongst other benefits).  In the 7^th principle he illustrates how many small experiments (tasks) produce less variability then one big one; resulting in faster feedback and reduced variability in the outcome (read: Predictability).

Don’t Overcommit

Superman says “Don’t worry ma’am, I’ll stop that train”, and the action hero always tells the distressed damsel “I won’t let anything bad happen to you”.  Big promises, but whether through superpowers or a Hollywood script they know they can back it up.  We are not Superman nor are we action heros, overcommitting in the real world just gets people hurt.  So, why do we try? 

The reality is that the real heroes are the ones that understand their limitations and what they can and can’t do.  They don’t put their team’s reputation in jeopardy by overstating what’s possible.  (In the same light they don’t sell their team short by under committing either).  The tricks to this step are to learn from recent history.  What did we get done last sprint?  Did we over or under commit?  If we over committed, what was the main reason?  Were we optimistic?  Did we not see the risks or dependencies in the committed work?  One of the great powers of the Retrospective is to answer questions like this, to inspect and adapt by improving our tasking and commitments.

Planning for Done

Dwight D. Eisenhower once said “In preparing for battle I have always found that plans are useless, but planning is indispensable.”  We task out stories to find the inherent risks and dependencies in a story, not to track our time.  Working together as a team at the beginning of a sprint to task out the committed work will identify many hidden risks and dependencies early on, as well as lead to a confidence factor in completing the work.  If risks and dependencies are discovered, or the confidence factor is low, early in the sprint is the time to discover this.

However, do not mistake this for a waterfall in a can.  We task out enough to understand how we will approach the problem, but we don’t write a full on requirements document before we get started.  We share a common understanding of the acceptance criteria, but also understand those may change slightly as we learn about the feature during the sprint.

Swarming

The practice of swarming on a story is under-utilized in most scrum teams.  Look for a blog in the near future on this topic, but essentially this means everybody that can works on the top priority story until it's done.  I equate this to bees on flowers; as many bees as possible go to the first flower, if it's full then the remaining bees go to the next flower.  However, the bees don't spread out across the entire field, they stick together and move from flower to flower almost as a unit.

Forces from above...

One of the primary reasons for overcommitting or taking on too big of a chunk in planning is the forces from management and product ownership to “get more done”.  That kind of pressure is ok; management and Product Owners should expect a lot out of their agile teams.  However, make sure that from a team perspective you are counterbalancing that pressure with the right amount of reality (through conversations during planning and backlog grooming ) and predictability.  It becomes far easier for management to accept what they consider a smaller commitment once they become used to the fact that what is committed will be completed.  It is better to under commit as you work to get better at these practices; having time available at the end of the sprint is not as anti-productive as you might think.  Become predictable and the trust from management will follow.

Avoid the Icky…

When planning out your sprints, keep this in mind: At the beginning of the sprint you made a promise to your product owner to provide a certain amount of value.  Make sure your plan convinces you that you will be able to uphold this promise.  Take a confidence vote on the plan, raise your voice when you don’t feel comfortable with the plan, ask the right questions at the beginning of the sprint.  If you miss that goal, inspect and adapt during the retro to address the reasons for falling short and follow through on the proposed actions that result.  Becoming predictable should be one of a team’s few top goals.  Work to make sure you don’t have to kiss your sister again.

Vertical Slicing - Tips and tricks for breaking up complex user stories

 Some (many) user stories just don’t fit neatly into a sprint, at least in a true state of done (tested, accepted, deployed, consumed).  Trying to provide true business value with each story while still meeting Definition of Done can be difficult to complete in a sprint when the feature has any complexity.  One of the most common is when a story is about adding or replicating chunks of a feature that don’t appear to be separable without losing business value.    I have often seen teams falling into the habit of breaking up user stories into technical components or separating testing from development across sprints because they are unable to complete the original story in one sprint.  The common fall back is to break a story up into database, coding, testing and analysis pieces, all meant to be worked on in different sprints.  This leads to many problems, such as fragmented development efforts, low quality, and inability to demo and deploy working software.

For example, let’s assume that the business value the team needs to deliver is resolving to the window shown being added to the application.  This is a simple window that provides a grid displaying customer data and a set of controls that either affect the displayed customer data or handle user requests (Save/Cancel).  Teams new to agile would look at this screen and deem that they need to complete all the operations in this window in one shot to add any value, which makes it too complex for a single sprint.  However, there are several techniques that can help to break this story down into manageable chunks.  

Spikes

Spikes are a type of user story that answers a question instead of adding direct business value.  For our example, one or more spikes may really help to reduce the complexity of the story by

•  Determining what data grid to use to best meet the user’s needs
• Solving a caching problem that the grid will need to operate correctly
• Doing A/B testing on best filters and control usage for the grid

Spikes still need to add value by answering a question, as well as needing to be testable and follow good acceptance criteria practices.

Vertical Slicing

This is a very powerful practice, but one that is not used as much as it should be as many teams do not understand how to break out individual user value.  Vertical slicing practices state that we try to find the smallest piece of user value in the parent story to break out into a child story.  (note: this also supports the concept of small batch sizes).  For example, if we were to just tackle the grid view first and do all work needed to display data (database, UI, middle tier, testing) we could demo that to the PO (and, potentially, beta testers) to obtain feedback.  Does this provide value to the business?  Yes, since now we can verify that this grid approach is the right approach and gain feedback as to columns, sorting request, display properties, etc.  All of these would be difficult to obtain without having a working application for stakeholders and users to provide feedback against.  The important point is, if we decided to release this as is we would be able to, as we have fully unit/system/integration tested this capability.

Mock Objects

Another way we can break this up and still provide value is to use mock objects to replace real functionality so that we can focus on one part of the screen at a time.  For example, what if we created a mock object for the database response and just stubbed out handlers for each of the radio buttons and check box.  The database object would return a sample dataset (without ever leaving the application module) for display in the grid.  With these stubs in place we could focus one sprint on completing the functionality of the grid, including full testing and acceptance.  How does this add business value?  By showing the PO what the data will look like in the grid and how it interacts with the other controls allows her/him to determine if this is the right approach.  Could this feature be deployed and released to a customer base? Under the right conditions, yes (beta testing, etc), however we are still providing business value by providing information to the PO to confirm or correct the direction.  After all, that’s one of the bedrock principles of agile practices, to quickly collect and react to feedback.

An additional benefit of using mock objects is testability.  These mock objects remain part of the code base and are used in automated testing to isolate the behavior of real world components.  What if we are having a display issue with the grid?  Using the mock object that is guaranteed to return the expected dataset will isolate the problem to either the grid or the database object.

Go from this

To this

Acceptance Criteria

One more tool used in slicing stories is to review the acceptance criteria.  First, make sure the acceptance criteria are in place and the team and PO agree that this is what done looks like.  Now, look at the AC’s.  If there are multiple, can one or more of the AC’s become a story by itself?  Can more complex AC’s be broken up into smaller context so that they can be done in a separate story?  Often times reviewing the AC’s for story slicing helps to improve the criteria for the feature in general.

Reducing Risk

We break down user stories for many reasons, but one of the important ones is to reduce the risk associated with the feature.  How do we know that what we are planning to build will meet customer needs?  How can we be certain that we are using the correct technology?  These and other similar issues are what creates the risk around each user story we are planning to implement.  Decomposing these risks into smaller ones reduces the overall risk on  an exponential scale. (Donald G. Reinertsen, "The Principles of Product Development Flow")

Bottom Line

The Bottom Line is this: the smaller the batch size, the faster the work flows through the process.  Don’t be afraid to be creative with how you slice stories; very often after slicing a story down and doing a few slices we find that we don’t actually need the other slices.  Think lean and doing only what is required to delight the customer.  Think about ways to deliver value in smaller increments, but remember to always provide value with each slice.

Shared understanding - Why we size work

I think one area I get the greatest satisfaction as an agile coach is when I see a team really start to understand why we size things (rather than traditional estimating) in agile environments.  When I see the “ah ha” moment and the light bulb goes on it’s always a huge step in both their team formation as well as their understanding of some of the advantages of agile principles and practices.  They really start to understand the agile principle of communication over process.

It’s the discussion that allows us to come to a common size that really counts, not so much the number that we arrive at.  It’s the shared understanding of the business need and, from a lean perspective, what is enough to satisfy the business need and what is overkill.  Sure, having each of these items slotted into like sized piles is helpful for sprint planning, release planning, etc, but to me they are almost side benefits, and not the core benefit.

My favorite example.  Our product owner has asked us to provide a way to get across a waterway.  As team members, you might initially vote this as a 40, believing that we need to build the Golden Gate Bridge over the bay in San Francisco.

But I may vote it as a 2, because I think all we need is a log over a creek.

After we discuss the real business need with our PO, we settle on an 8 since we form a shared idea of building a simple bridge that still meets the business need.   The discussion required to arrive at this number brought out what the business really valued (provide a way for foot traffic to cross the creek) and the constraints involved (make it simple, yet attractive)  We now have a good idea of what done looks like (able to walk across the creek) and how to test it (allow up to 10 people at a time on the bridge)

It’s the power of these discussions that really brings the team into a unified vision of what business problems we are trying to solve, and a shared understanding of how we might solve those problems.  These discussions are what allows us to become more effective and efficient at saying if meeting this business value is bigger than a breadbox.

The All Too Missed reason for Scrum Standups

There is a non-stop parade of blogs and other instructional material on stand-ups.  What makes them effective?  And what are they REALLY for anyway?

Why do we have stand-ups?

The real reason for the Scrum Stand-up is to re-plan for the next business day what we need to do to achieve our sprint goals.  We come together to find out how far we got since the last stand-up (but not a status update!), what we learned from doing those activities, and what our direction and plan should be until the next stand-up.

What I did, what I’m going to do…

The three guidelines of the stand-up (what I did yesterday, what I will do today, any impediments) are in place to help us get to the right information as to what to re-plan.  What I did yesterday is only important to the rest of the team so as to illustrate what is completed and no longer an issue for us to meet our sprint goals, and to provide anything learned from those activities to get closer to or better at attaining those goals.  That's why it's not important that I only got one thing done yesterday because I had a ton of meetings (that will come in the impediments part); from a "How did I help move the team toward its goals" perspective, this is unimportant.  The fact that I was able to get a new test harness in place or confirmed the accuracy of a business rule we are building will really help the team in its re-planning efforts.  Sharing progress simply so that the other team members know what I accomplished (status update) is wasteful of the full groups time, since the team should be able to see actual progress from sprint boards and the like.  "What I plan to do today" is stated to share with the team what I think my role is in meeting the teams goals (till the next standup) should be.  However, as we re-plan, the team may elect to change my intended direction based on other impediments or changed direction.

Remember this diagram from Scrum training?  The "24 Hours" loop is the point at which we assess what we have completed, and what we should do next to keep moving towards the sprint goal.  This is the opportunity to apply the knowledge gained from the “what I got done” part to help the “what I will do” part.

The Impediment Factor

So now let’s talk about impediments.  Why should everyone else on the scrum team care that I have 3 meetings taking up my time, or am struggling with rebuilding that test harness?  They care because we are all pushing towards the same goals, and need everybody effectively pushing in the same direction to attain those goals.  Perhaps someone else that has bandwidth can take one of those meetings so that I can focus on the test harness.  Perhaps someone else has more experience and can help me with it, but then needs to offload what they had planned to another team member.  Maybe that test harness is no longer high priority and should be returned to the backlog?  Sharing impediments in a standup is a way of saying “I have these issues, what should we as a team do about them?”  The re-planning comes in to help us shuffle priorities for each team member, and possibly even for the sprint goals.

Why do we re-plan every day?

From the Scrum Guide from Scrum.org

Scrum is founded on empirical process control theory, or empiricism. Empiricism asserts that knowledge comes from experience and making decisions based on what is known. Scrum employs an iterative, incremental approach to optimize predictability and control risk.

We just spent 24 hours working towards a goal, the knowledge we gained during that time should help us re-plan, right?  This is the learning part of the do/learn/plan cycle that we go through each day in our effort to inspect and adapt.  We don’t wait until the sprint demos or the retrospective to adjust our direction; we do this on a daily basis.  Addressing impediments, re-planning based on what we learned, and adjusting the tasks involved in reaching that goal are all part of this re-planning process.

It’s the evolution of the ceremony

Scrum, as per the Scrum Guide, is

·         Lightweight

·         Simple to understand

·         Difficult to master

Advancing the Standup along its intended course of improvement from just answering the three questions to an evolved re-planning session is part of that “Simple to understand, Difficult to master” evolution.

Spikes – The Value of Information Gathering

User Stories have become the defacto standard in agile development to convey business needs to agile development teams.  There are countless posts and informative books and articles on how to write great user stories, but the essential statement of what a user story encompasses is to provide a short snippet of information that stimulates a conversation about adding value to the product.  Good user stories employ other attributes, such as valid acceptance criteria and following guidelines such as INVEST (Independent – Negotiable – Valuable – Estimatable – Small – Testable).

However, there is another type of story that is very useful: the Spike story.  A spike story is essentially a learning opportunity that we have discovered and want to explore.  The main difference between a spike and a user story is that where a user story adds value, a spike story answers a question.  Spikes allow us to do valuable work without necessarily adding direct (immediate) value to the product.  Spikes give us the ability to do research and knowledge gathering while including the needed constraints that a story framework provides. 

When to use Spikes?

Spikes are very useful in situations like the following:

Scenario I:  A user story has a well-defined business value, but we are unsure how to approach it.  For example, the user story calls for a particular grid capability on the user screen, but the team is unsure what the best technology is to accomplish this, and the outcome will influence the product owners view of the feature.  The team can create a spike story to create a working prototype for the PO to review to help define the feature and its acceptance criteria.  We can provide knowledge to the PO to help her/him see what is possible in creating business value, to be able to answer questions like “Is it realistic to have acceptance criteria that requires the ability to mix different data elements? “

Scenario 2:  The story is too complex, and we can’t find a way to break it into smaller business value chunks.  Can we solve some of the technical issues behind the story to reduce the complexity?  Can we do research on possible solutions to help reduce some of the uncertainty?  Let’s take our grid example from above, but what if the complexity comes from unknowns on how the new grid will perform with the current database technology.  Perhaps we can do a Spike on how the grid can consume the data in a performant way?

Scenario 3:  What if the PO has specified some business value, but the team has no clear idea on how to implement it?  This is another good usage of a spike, and can use techniques like A/B testing or beta tester feedback loops to determine the best way to move forward.  The team can use information from the PO on the vision of the feature, and experiment with different options to help further define that vision.

Keep it focused on value

One caution on using spikes: do not abandon the guidelines and constraints we apply to user stories.   Just because we are gathering information does not mean we can toss out the focus on business value.  Make sure that spikes still have a good title and description that define the conversation to take place.  Ensure that you are using the proper voicing in the story so that you maintain focus on who will be helped by this information.  Hint: it is common and acceptable to use the PO or team as the role needing the information, but avoid a specific role on the team, such as developer.  The entire team should be able to consume and learn from the knowledge gained.  Above all, make sure that you define and agree upon what “done” looks like in the form of good acceptance criteria.

By Example

Going back to our grid example, let’s see what a spike story might look like. 

Business Value: Give the user the best experience when merging their media files in their library.

Spike Story: As a product owner I want to learn about different ways to allow the user to merge media files in their library.

Acceptance Criteria: Verify I can review 2-3 options for merging the data.  Ensure that I can accurately compare the pros and cons between the different options. 

Note that the acceptance criteria does not specify being able to actually merge the data, since we are not trying to solve the user story, only the spike.  The important part is that we provide the knowledge in a consumable format.

Quest for Knowledge

One of my favorite facets of agile development is the importance of acquiring knowledge, and applying it to reach our goals.  This is evident in the agreement with our stakeholders to invest in this knowledge acquisition.  Spikes are the contracts we use to justify these explorations and discoveries. 
Donald Reinertsen discussed in his excellent book "The Principles of Product Development Flow" the principle of buying information.  "Information reduces uncertainty.  When we reduce the uncertainty of an economic outcome, we create economic value."  Columbus and crew went looking for a short cut to Asian spices (perceived economic value), but came back with the (re)discovery of a new world (unexpected, but far greater economic benefit).  Sometimes those investments return value we never saw coming.

The advantages of One Week sprints

2 week sprints are boring.  Been there, done that.  So many teams starting out an agile project, especially in a team new to agile, select the default 2 week sprints without really knowing why.  Not that I’m against 2 week sprints, but the biggest part of selecting a sprint time box is knowing why you are selecting that, e.g. What is the value?  (BTW, I try at all costs to avoid 3, 4, 6 week sprints)

One of the big advantages of the practice of time boxing feature work (sprints) is to have a clear end point that is not very far out, so that we can see the finish line often (small batch sizes), and when we reach it determine if we are still going the right direction (inspect and adapt).   Determining what this end point should look like and how often we should inspect/adapt is a difficult skill to obtain.  We as humans are really, really bad at predicting the future, and the farther out we go the worse we get at it.  Especially for a team new to this practice.

My MO when coaching new agile teams is to encourage the team to start with one week sprints.  There is often a lot of concern and push back from this, with the usual arguments “we can’t get anything done in a week” or “it takes too long to deploy to do it once a week”.  The answer to those concerns is that if you can’t do this in one week you won’t be any better at in two weeks.  These objections are always symptoms of underlying problems, such as the deployment capability is not utilizing continuous delivery practices.  Getting a team to work in smaller time boxes will force them to learn to work in smaller increments, which is a core skill they need to obtain.  Learning how to break up a story into the smallest business value they can will strengthen the team’s ability to deploy business value more often, striving towards a daily (or more frequent) change to production. 

In doing initial training I have sometimes put teams in a one day sprint pattern.  Start the day out with deciding what we need to accomplish by COB that day, and set about doing it.  It becomes glaringly obvious where the issues are in the code base, deployment, and product vision/understanding as the team struggles to break down the features into something tangible and deployable in one day.  Sticking with this results in, at a minimum, a team that understands how granular we want to work, and usually provides a pretty good list of spikes to resolve to improve the deployment process.

My motto has long been: if you can’t succeed with one week sprints, you will be terrible at two week sprints.  The problem is, the larger the time box the more the weaknesses in the team and the process will be masked.  Agile is very much about constantly inspecting what we have done and adapting for what we still need to do.  The larger the time box the less agile we become.  Try to succeed with one week (or smaller!) sprints before moving on.   And, as always, if you want to change this practice make sure you understand what problem you are trying to solve by making the change.