April 24, 2014

All Posts Tagged With: agile

Agile Coaching Blog

Generation Agile

When I posted to my twitter account earlier this week about the presentation my wife and I gave at the Global Scrum Gathering, Paris 2013, on The Agile Girl Scouts , a friend of mine asked me to put some context around it. He was able to understand that the Kanban and Scrum Training for Girl Scouts was a pretty big deal to me, but was’t sure why. My hope is that this blog post will provide some explanation around that.

The Waterfall Waterfall PNG

Most adults in the workforce today have learned how to manage work using a waterfall model. That means work follows something along these lines:

- Initiation – We figure out what we need to do
- Planning – We figure out how we are going to do it
- Execution – We do it and try to follow the plan as best we can
- Monitoring and Controlling – We check to see if what we delivered is what was wanted
- Closing – We shut it down and capture what we’ve learned along the way.

Bag of Oranges Days
For many of the people who adopt this method, success comes from a command and control approach. This approach tends to view people as “resources” which are expended on a project to achieve a specific end. In the IT space, it has a history of being successful about 30% of the time. For the person acting as Project Manager, it often leads to a lot of “bag of oranges“days.

When I learned and later began teaching this model, I kept wondering why no one had taught me that stuff before. The simple tools it provided, seemed more like common sense. Just having the simple capacity to see an overwhelming amount of work and have the basic tools to break it down into manageable, workable elements was very enlightening. Since then I have been looking for ways to go back and teach my younger self some tools that would have made life a lot easier.

Those tools were great, but using them was a bit like Frodo putting on the ring. The more I used them, the more I started to feel that I was supposed to try and control the uncontrollable and the more I started to view the humans I worked with as “resources” and not people. They were pawns on a chess board and I was playing chess against an opponent I could not hope beat because the only thing I could be sure of was that whatever I was able to imagine, predict, or plan for, was the only thing that was not going to happen.

When I entered the workforce and started to work for people who had been taught that success came through control, I was often the pawn on the board. In many jobs I was micromanaged, condescended to, accused, blamed and generally treated like someone who could only be counted on if they were bossed around and threatened. I, in turn, reluctantly learned this approach and tried, to apply it (with limited success). This didn’t happen all the time. I was lucky to have a few really great bosses and teams along the way and I was fortunate to find myself in situations where I really was able to be creative and collaborate with other people who cared as much about the work as I did. Those moments were invigorating.

The Agile Manifesto
As part of a response to the waterfall approach, in 2001, a bunch of smart guys got together and came up with the Agile Manifesto, which says:

We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:Individuals and interactions over processes and tools
Working software over comprehensive documentation Customer collaboration over contract negotiation
Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more.

In my journey towards adopting the above and learning to use the models and frameworks which support the Agile Manifesto, a lot of what I do is a reaction against the traditional command and control approach I had been taught. I often joke that I am in a state of recovery, but I do tend to view it that way. One of the reasons I get so much joy from what I do for a living is that I get to help others on their transition as well. But I do think it is important to acknowledge it as a corrective action.

Hope for the Future
Any parent wants their child to have a better life than they did. We all want for our kids to experience less adversity (or at least different adversity) than we did. If Agile is about creating a work environment that values people, their ideas and ability to collaborate in an effort to deliver higher quality work, then it is a very positive and healthy response to a workspace that did not support creative collaboration and self-organization.
Each new generation finds that certain things which were common in previous generations, are no longer good for us. When I was a kid we’d go to the Jersey shore in the summer. If my Mom was able to get some Coppertone SPF2 or 4 on me it would only last until I was able to get to the water and scrub it off. I’d play, swim and lay in the sun until the blisters formed. The blisters were an indicator that maybe it was time to put on a t-shirt, a baseball hat, or in extreme cases, SPF 15. My daughter has been spared that due to how much more we know about the damage the sun can do to our skin.

My goal with teaching Agile to young people is similar to educating them about the dangers of too much sun. My hope is that if they learn about Agile first, their experience with it and exposure to the benefits it can provide will “inoculate” them against some of the challenges they would otherwise face if they entered the workforce as “resources” to be used up on a waterfall project. My hope is that they will see Agile not as a response against something else, but as a natural, organic way for empowered, creative people to deliver high quality work.


Extending Cross-Functionality to Programs

There is an excellent rationale for cross-functional teams.  For large programs, that rationale can be easily scaled to the program-level.  But, for some reason, this isn’t always recognized.



Let’s say you have a team with the following profile of highly siloed individuals:


 This is great if you have a profile of stories that fits it perfectly, as follows:


But what if your set of sprint stories looks more like this?:


In this case, you have a deficiency of analysts, back-end developers, and QA people to implement the stories that your aggregate team capacity might otherwise support.  And, your UX folks and front-end developers will be twiddling their thumbs for part of the sprint.

So, what to do?

Since you are only as good as your lowest capacity component (which appears to be QA, from this particular example), you will have to scale back the number of stories to fit the profile, as shown:



Now, everyone is underutilized, except for QA.  Good luck finding something useful for everyone else to do in the next two weeks.

The net result is that your team is perhaps 30% less productive than it could be (eyeballing the graphic).

However, if you take advantage of standard cross-functional teamwork, your team’s profile may look something like this:


Note that by “cross-functional” we do not mean that everyone should be able to do anything.  There are very valid reasons (education, experience, proclivity, enthusiasm) why certain people are ideally suited for certain kinds of work.  Think of the cross-functional nature of someone’s role on a team as a bell curve (alternatively, some talk about T-shaped employees – the T is just the bell curve upside down, as the Y-axis orientation is arbitrary).  The more the curve is spread out, the more they are able to take on other people’s roles.  On a good cross-functional team, the bell curves overlap “somewhat,” meaning that everyone can take on a little bit of someone  else’s role, although perhaps not as efficiently.  Still, this allows a team to take on a wide variety of “profiles” of sprint work, as will always be necessary.

So, for example, in the case above,


people will adjust to the desired “sprint needs” profile as follows:




Don’t forget that this model can be applied to more than just teams.

For example, there can be a tendency for teams to develop “specific expertise”, due perhaps to knowledge held by certain BSAs or specific architectural or design skills in the development team.  The program may then tends to assign stories based on this expertise under the theory that this is the most efficient way to get work done. Unfortunately, this has the effect of only further driving each team into a functional silo.  It can become a vicious spiral and soon you may hear things like “well, we don’t have generic teams and, at this point, the schedule is paramount, so we need to keep assigning program work according to the team best suited to do it.”  As a result, program backlogs will consist of stories pre-targeted to specific teams, even arbitrarily far out in time.  Imagine what happens when the stakeholders decide to re-prioritize epics or add new features, or a new dependency arises that doesn’t line up with the ideal team at the right time.  The result will be a work profile that doesn’t match the “team profile,” as follows:


Enter a cadre of fix-it people – project managers, oversight groups, resource managers, program managers – all trying to re-balance the backlog, shuffling stories around, adding people to teams, squeezing some teams to do more work, while other teams tend to be idle, therefore resulting in the assignment of less than necessary filler work.  It is the same wasteful resource management nightmare that is so easily solved by cross-functional teams, except this time at the program level.

So, eliminate the waste, and follow the following simple program level guidelines:

  1. Create a fully prioritized program backlog without consideration for the teams that will be executing the stories.
  2. Once per sprint, have a program planning session or meta-scrum (Uber-PO, Uber-SM, team representatives) where the candidate stories for the upcoming sprint are identified for each team.  Include a little more than each team’s velocity would otherwise indicate in case they are able to take on more than their average.
  3. Make it a goal to avoid specializing teams.

All team “profiles” will be identical and program needs can easily be accommodated.



There may be a little bit of short term inefficiency resulting from having the “slightly less than ideal” team work on particular stories, but the more you do this, the more that inefficiency evaporates.  And the advantages are significant:

  • Holistic view of program backlog allow you to focus on what is important – delivering value
  • No need to engage the expensive swat team of fix-it managers to shuffle around people and project artifacts
  • All team members gain experience and learning, often resulting in greater job satisfaction, and higher performing teams
  • No more single point of failure; no more critical path team
  • Far less chaos and confusion, resulting in more focused individuals
  • Extremely easy to manage – program progress is measured by the simple rate at which all teams work through the stories.  Any gaps in targeted scope versus expected scope is easy to identify.



Want additional actionable tidbits that can help you improve your agile practices? Sign up for our weekly ‘Agile Eats’ email, with “bite-sized” tips and techniques from our coaches…they’re too good not to share.


“Concept-to-Cash”: A 7 Minute Agile Case Study

Concept to Cash

Got seven minutes to spare? Click on the link below to view this intriguing segment on a client’s agile case study about how an organization increased its efforts to make better business decisions and execute faster to get their product from “concept-to-cash”. They began with cycle times that took months but refined their delivery to weeks and even days. Through a phased approach, I explain how our coaches analyzed the company’s value stream, and using agile practices, worked to mitigate their constraints.

Concept-to-Cash: A 7-Minute Case Study


Seeking Consensus, Not Perfection

"Tell me, I’ll forget Show me, I’ll remember Involve me, I’ll understand" - Confucius

“Tell me, I’ll forget
Show me, I’ll remember
Involve me, I’ll understand”
- Confucius

When I first started my career as a software developer, I always thought that the truly tough problems were the technical issues. I assumed my job would entail creating complex formulas, walking through long chains of logic, and learning new technologies that stretched my understanding. I don’t mean to say that I didn’t do all of these things – and enjoy them thoroughly – but I came to find that they were not the greatest challenges I faced in getting a group of people to solve complex problems. Over time I tried numerous job roles including project manager and analyst trying to figure out the best way to come up with solutions and “get people to do them”. Only after several years of limited success did I realize that only by getting people to understand and become part of defining a solution, could we truly achieve great things. In order to do this, it can’t be just about me, my solutions, or my great ideas. This is very difficult in many organizations today that embrace specialization and explicit roles of traditional software development. Each person has their specialty, which they “own”. There is limited need for true collaborative or meaning making conversation. The analyst is the expert in the requirements and shouldn’t be questioned; the architect’s design is beyond reproach; and the UI expert’s opinion is infallible. All of these people may be excellent at their jobs, but this is a model where they can easily talk right past one another and miss opportunities to truly make break-through products.

[Read more...]


An Experiment in Learning, Agile & Lean Startup Style

I always have a backlog of non-fiction books to read. Given the amount of free time that I have every day, I am guessing that it may be years before I get through them. In fact, the rate at which books get added to my backlog probably exceeds my learning velocity, creating an ever-increasing gap. It feels like a microcosm of Eddie Obeng’sworld after midnight.”

So what to do?

learning agility

I am trying to increase my velocity by applying speed reading techniques. But so far, that is probably only closing a small percentage of the gap.

Iterative Learning

Then, upon a bit of soul searching, I had an epiphany. Why do I feel the need to read and understand every single word on every single page? This runs counter to what we coach our teams to do—eliminate waste, only document what makes sense, just-in-time practices, and applying iterative thinking instead of only incremental. The answer seemed to be that I don’t feel that I have really read the book if I haven’t read every word. So what? Am I trying to conquer the thing? It seems like a very egocentric point of view.

What if I was able to let go of the ego, and try to read a book iteratively instead of incrementally? Is it even possible? Would it be effective? [Read more...]


BigVisible Webinar: Transformation Beyond Agile Teams

The latest Webinar by BigVisible co-founder George Schlitz and principal agile coach Michael Hamman focused on how to keep the agile energy flowing beyond agile teams.

As more and more companies attempt to leverage agile development practices toward increased business effectiveness, managers are beginning to realize the broader organizational implications of agile. They are discovering that true agility goes beyond just having agile teams.

[Read more...]


CEO Corner: Innovation and Agility in Practice

In a recent episode of Pulse Network’s CEO Corner, BigVisible co-founder Giora Morein discusses BigVisible, agile coaching, organizational agility & innovation, and how to convince executives that change is not only possible, but necessary. You can watch the entire segment here.

Key Highlights

Some key insights from the interview:

  • In today’s market, agility and innovation are crucial to success.
  • BigVisible coaches become true partners with their clients. The power of one and the strength of many means that your coach is entirely dedicated to you and your goals but has access to a large body of expertise.
  • Innovation is inherently high value and inherently high risk.
  • Most BigVisible engagements begin with solving a delivery program and quickly evolve to helping change organizational culture and rules
  • “Doing agile” isn’t the goal. Agile practices are one way to help accomplish your business goals.
  • Becoming a truly agile organization involves rewarding innovation and agility, which will likely include changes to everything from the organizational structure to compensation & bonuses.

Agility, Innovation & BigVisible

After a quick introduction of agile, organizational agility, and an overview of BigVisible, The Pulse Network CEO Steven Saber frames the conversation by saying that these days, “Everyone needs to be innovative .. There’s no longer an opportunity not to be an [agile] organization.”

Giora quickly agrees: “If you’ve got your MBA, you’re probably trained to … find the one right answer … and just follow the plan. [But] what if you’re dealing with a puzzle that you don’t know how many pieces [there] are, the pieces themselves are constantly changing, and the picture is constantly changing. .. Its not so easy to say there’s one answer because its a moving target. … How to navigate that ever-changing landscape is becoming and increasingly more important.” [Read more...]