Leading from the Middle

“The Key role of middle management is reinvention.” Tom DeMarco

Often I hear of Agile Adoption best occurring top down. Salesforce.com did that, from zero to Agile overnight. Other times I hear about bottom up Agile , or Agile in “Stealth Mode”. for a development team is tired of death-marches, a bottom up agile transition can be effective and motivating. This was how most Agile Adoption occurred 5 years ago when I was learning Agile.

And I rarely hear about Agile Adoption from the middle. Yet this is where, from my experience, change typically comes from. This is due to the fact that your middle management is typically where you have slack in a traditional organization. Slack is where you get your adaptability, because it is there that you have the bandwidth to try new things and aren’t under the optimization and efficiency pressure. If an organism or organisation is optimized, then it will be unable to change. Like the Cheetah who is far too specialized to adapt to new environments or prey, it will die off. Humans, however, can adapt to many environments because they are not optimized at any one thing, (except arguable solving problems and using tools).

Middle management has a role even in top-down and bottom up adoption. While they are typically directing operations and ongoing activities, they are the ones who are in charge of implementing change. As the Harvard Business Review states “First, virtually all major strategic initiatives have to be carried out by the middle managers.” In a top-down Agile adoption, while upper management might fund an adoption or read the “The Agile CIO” whitepaper they will need to ask someone to “go do it”.

This is hard work, in my opinion, especially in a situation where you are learning how to become a servant leader and drive change in the organization. This is why I think Scrum prepares teams particularly well for the role of change agent, as a Scrum Master is in charge of serving and protecting the team, which after the team gets its house in order moves to getting the organization’s house in order to support the team.

In the case when Agile is done in stealth mode, the team is doing the hard work of change. However, you need a line manager who interfaces with the other parts of the org, protecting the team while Agile is in its infancy, and heralding success when it has proven its value. This is where a good middle manager will be able to network with other middle managers, directors etc and socialize and herald change through the organization. Hallway conversations can reduce fear about the new “threat” and familiar faces can introduce it as a new option worth exploring. Again, a key element of this is adopting the courage to try new things and introduce change, without fear.

When I was first learning about Agile, I had a terrific manager (Philip Ljubicich) who empowered me to try new things and managed by exception. His motto was “If you’re not making mistakes you’re not trying hard enough.” A Microsoft vet from the very early days, he understood the concept that the minute you mange by methods, you’ve created a system that can’t cure itself. Microsoft, despite all its faults, has created a culture that believes it is anathema to tell your development teams how to work. It has kept their organization adaptable to many changes in the tech world for the last 30 years.

When I discovered this Agile thing, he encouraged me to try it out and see what worked. We tried it, it worked, adapted it and achieved great results. My point here is that had I not been there, had the capacity to learn and the support to try new things, we may have never tried this out. Only because I had a great manager, and because I had the slack to be able to adapt did we change course. If you’re organization doesn’ have managers like Phil, then your job is harder, which is why pilot projects where you demonstrate that Agile is safe and “we’re not switching to anything” until they prove their worth are a good idea. It’s easier to support what I know has worked in our organizaiton than a new untested theory.

In the nineties there was the empowerment craze of flattening org structures, of leaders with inspired vision and teams who shared that vision. People were doing trust-falls and climbing walls and holding hands and singing kumabya.  Middle management was seen as waste. Yet in this craze to flatten org structures organizations they flattened their capacity to change.

Toyota, which has shown itself to be remarkably resilient, past four recessions and the oil crisis, has a surprisingly deep org chart, with many managers for each of its employees. These line managers, however, aren’t career managers, they are those who have great technical expertise in the teams they manage. Why is this important? What happens when you have a spike in the work for a production line, or have a problem that you need to solve? This can go to the middle management core, who can help to eliminate impediments and educate and advocate for their teams throughout the organization.

Of course, the culture of middle management must support these changes, and have the courage to try new things. Otherwise, middle management can often be the biggest impediments to successful adoption, as they work alone, try to cover themselves so they rise to the top and otherwise try to optimize their own organizaitonal silos. Great companies have their middle managers frequently working together, learning and sharing ideas in a culture of collaboration, so they can achieve the strategic objectives of the top brass.

Posted in Uncategorized | Tagged , , | Leave a comment

“Hitting the wall” with your Agile Adoption? Try adding technical practices…

This is a great post that uses the familiar metaphor of the gym and physical fitness to apply to adopting Agile. I’ve seen the pattern described here too often.

Developers start out the first three sprints and produce production ready software every iteration. It seems like everything is going well. Then under the gun of the ScrumMaster to keep their velocity high, they build up technical debt (like sprinters developing lactic acid) by not paying attention to technical excellence and practices that will maintain a sustainable pace. This slows their speed to a halt until they clean up their technical practices and adopt test driven development, continuous integration, mercilous refactoring.

The question for me is not whether or not this pattern occurs, but how to best introduce Agile so teams can recognize when it is happening and address it.

On the Scrum side, folks like Mike Cohn suggest introducing Scrum first (using the iterative or requirements first pattern described in his outstanding Agile Adoption presentation). This has the advantage of allowing the team to self organize around the practices needed to maintain agility.

On the XP side, folks like James Shore recommend introducing the 12 XP Practices first (Mike Cohn describes this as “Technical Practices First” Pattern). The tradeoffs to Jim’s approach is that it is costly to start with all 12 practices from day one. Teams may reject the approach altogether, while getting none of the benefits of the practices. But the teams that do will have sustainable pace and agility.  The benefits to Iterative first or requirements first are that the teams learn how to self organize and undergo the cultural change necessary for bottom up commitment based planning. The downside is that somce Scrum is silent on engineering principles, and focuses on developing a self healing system rather than prescriptive practices. The down side to this is that teams may fail. Yet if they are using the retrospective and sprint review effectively, however, effects of failure are minimized (since they can inspect and adapt) and teams will have the added benefit of becoming a self healing system.

My experience is that the end state of having Scrum teams that us XP is a great combination. The paths to getting there are varied, and I’d rather a group learn how to think for itself then think implementing a set of practices will make them Agile. It’s the mind set shift to Agile principles that is important in my opinion, not the discrete practices used.  This prevents Agile and Scrum from becoming yet another prescriptive methodology that says “do these steps in these ways and you will be guaranteed success”.   What do you think? Have you experienced the pattern described above?

Posted in Uncategorized | Tagged , , | Leave a comment

The connection between sailing and software

I wrote this post about sailing “inside” vs “outside” the boat. I learned much from participating as a crew member on a sailing team. It positively influenced my work with software teams, as I’m sure any team sport would.

Posted in Uncategorized | Tagged , | Leave a comment

Bay Area Agile Philanthropy Group

A group of folks interested in using agile values and principles to give back to the community is going to meet in January to charter the Bay Area Agile Philanthropy User Group (BAAPUG). This will be on January 17 at Tacit Knowledge headquarters and we will define the community, the mission, vision and values of the group. If you’re interested in attending the chartering meeting, or discussion what we’re about further, you can join the Yahoo! group here. This group is based on inspiration from Bob Payne at Code Green Labs, creating events where people could both participate in an agile project and help out a non-profit at the same time.

Posted in Uncategorized | Tagged , | Leave a comment

How will we demo?

If you are struggling with concrete enough acceptance criteria, acceptance criteria that doesn’t specify the “how”, just the “what”, one technique that I find especially helpful is specifying “How will we demo?” to the story. This usually puts the product owner and the team in the right frame of mind for what we’re getting at with acceptance  criteria something both specific and actionable. For instance, if you are designing a shopping cart, the question “How will we demo this” may bring up a discussion of one book from the catalogue being searched for and added to a shopping cart and displayed for view. Typically I’ll have this as part of the template for a story card. Part of the beauty of this method lies in the act of imagining what will count as done in the future. There is something about the act of forcing humans to “remember the future”, of what the screen or web service will look like in two weeks during the iteration demo, that helps substantially when trying to get enough detail to estimate or commit to a story.

Posted in Uncategorized | Tagged , | Leave a comment

Restickable Glue Stick – Another reason 3M has a stranglehold on the Scrum Community

I like 3M post-it notes for sprint and release planning. It makes it really easy to have multiple people interact with stories and tasks. Unlike electronic tools, I don’t become a bottleneck for planning. However, I’m not against electronic tools.  In fact they make sense for distributed teams and for backing up data that is on cards. So, what’s a girl to do?

3M Restickable Glue

3M Restickable Glue

This is where the 3M restickable glue stick comes in.  It’s like regular glue stick, except you can use it to make anything into a repositionable sticky note. This means you can print your backlog from Excel, Google docs, Rally, VersionOne, etc. onto paper sheets or Avery card stock, slap some restickable glue stick on each story, cut them out and stick-em to the wall. When the product owner wants to change priority on a story, just pull it up and move it and stick it where you want it. Rather than hard to use clear Scotch tape, which is hard to unstick, or bright blue painters tape which may cover your story card, this is hidden and easy to use.

One stick of this stuff lasted me about 10 sprint planning meetings.I recommend a stick in every Scrum Master’s kit.

In a later episode, I’ll explain how I like to print out my backlog to Avery card stock to make planning easy.

Posted in Uncategorized | Tagged , | Leave a comment

David Anderson Speaks at Bay Area APLN

I attended a special meeting of the Bay area APLN chapter. David Anderson gave a talk on his recipe for success with Agile. Here are the notes. It was a good talk. I especially liked his description of how he pulled his development teams in to an all hands meeting on his second day on the job to give the teams permission to not write bugs any more. That is great servant leadership.

Admission Ticket for Quality Work

Admission Ticket for Quality Work

This reminds me of a similar struggle I had once with an individual on a development team when I was a team lead. The team wanted to try TDD and he was very opposed. He was the technical lead on the team, and we had a good relationship. After trying various techniques, tutorials, pairing with those who knew TDD, an “intervention” meeting with upper management, I realized that it wasn’t the lack of knowledge or clarity around our support for for TDD that was the issue. So in our one on one meeting, I asked him what is holding him back from endorsing this. After a long while of discussion, it came out that he felt that using TDD would slow the team down, and we wouldn’t deliver as much value to the client and might miss the date.

Aha! There was the tyranny of the schedule rearing its ugly head again. I realize that I had put him in a position where he had to both A) be in charge of the technical quality and B) was responsible for hitting a date with a fixed amount of functionality. I was the problem! So, rather than go into argument about why TDD is a good idea (he knew it was, but was under an impossible iron triangle problem) I told him that he was no longer in charge of making us hit the date. He was only in charge of delivering high quality software. I would take care of the delivery problem.

Rolling the Dice on Quality

Rolling the Dice on Quality

And you know what happened? The team embraced TDD, quality went up and we went faster because we stopped having to track and fix bugs from previous sprints. This all came back when David was discussing his slide on Giving Teams a Permission Slip for Quality.

Posted in Uncategorized | Tagged , , , | 1 Comment

Planning Poker Timer

Timers are valuable when you want to timebox a discussion. I’ve used this planning poker timer when I’m with a team and we are planning our iteration. I also use it when setting 30 minute work goals for myself. It has a nice bell when the time runs to zero, and changes from green to red, giving a nice visual cue.

Mickey Phoenix created this manual planning poker timer which I like even more, if you’re into analogue. kind of a Rube Goldberg contraption with a sand timer and a bicycle bell.

A homemade planning poker kit, timer and Mike Cohn's Planning Poker Cards.

A homemade planning poker kit, timer and Mike Cohn's Planning Poker Cards.

Posted in Uncategorized | Tagged , , , | Leave a comment

Distributed Cognition, marrying GTD with Agile Collaboration tools

This article by Francis Heylighen and Clément Vidal points out an interesting opportunity to leverage the concepts of external cognition tools like David Allen’s Getting Things Done methodology to assist in the working world for a collaborative environment that supports distributed cognition. While the paper describes a help desk ticketing system, when they discuss a points based system for organizing and estimating work, they are really talking about a system that we use in agile to do collaborative planning. I have often been toying with the idea of a connection between agility and GTD, but haven’t really figured it out until I read this article. What planning with sticky notes allows us to do is to get things out of our head, a GTD principle, and use distributed cognition to leverage the higher order intelligences of our mammalian brain, rather than our reptile brain.  Rather than having to keep stories or ideas in our head, in a contentious meeting, for instance, we can collaborate together if we get all of our ideas onto sticky notes and put them on a wall. Now we are free to group and prioritize the ideas using multi-dot voting to come up with the best idea. Part of this process that is so compelling to me, is the idea that once you stop using your brain to remember things (and we probably only have a 2 week memory for events and experiences anyway), we can use physical reminders of things to remember stories, risks, features, vision so our higher order thinking can come in and consider alternate approaches or scenarios, without the concern of forgetting details.

Posted in Uncategorized | Leave a comment

Use Parallel tracks for user experience work

At the APLN Leadership Summit I was fortunate enough to attend a track led by Arlen Bankston and Jeff Patton that discussed some of the patterns and practices that are beginning to emerge for incorporating user experience into the agile process. One of these that I found particularly refreshing, and common sense, was the notion of using parallel tracks of development between the usability folks and the development team. Far from the stern warnings of “big design up front” that are proscribed by agile methods, this practice is lightweight, rapid and allows for the development team to hit the ground running with a well designed interface to code to when the sprint begins.

Parallel tracks basically tells your usability team to stay 1-2 sprints ahead of your development team. During this period, they are doing paper prototyping, interviewing users, creating personas, developing scenarios and rapidly iterating on rough mockups of the design with actual users to discover usability bugs. After a sprint of prototyping and developing, the usability team has a conversation with the development team about the stories that are going to occur in the next sprint. The stories are sized and negotiated between the product owner, the designer and the developer.

For example, A developer might point out that what would be a 13 point story for a search interface design, for instance, might be accomplished in only 3 points with a couple tweaks. This meeting might be called a product definition meeting, and could occur a day or so ahead of the sprint planning to give the design team a chance to change the design after the developer feedback. The development team then develops against the design for the next sprint. Meanwhile the design team is busy preparing the next top eight or so stories from the backlog that the team threw into their next two sprint’s lookahead plan. If the development team had delivered any functionality from the previous sprint, the user experience team can start engage in user testing on those stories.

This approach was discussed in an article by Desiree Sy who used this process at a company called Alias, which is now AutoDesk. I have a crude drawing of the approach described in the article, shown below:

Parallel Tracks

Since we were in a modified Open Space format, there was a fair bit of anecdotal confirmation from practitioners attending about the value in this approach. The fascinating thing was that for the individuals in the room, some with many years of scrum experience, you could see there was almost a visible sigh of relief, as they realized that others were using this practice, and that it wasn’t “wrong”. However, as it worked with many teams who had not previously read about this approach, it is looking promising as an emerging best practice.

One of the reasons I believe that this method is consistent with the agile approach, is that if you consider the usability and user interaction designers as strongly allied to the product owner teams, they are actually using a common best practice which is to keep a backlog that is well groomed for the next few sprints. A good user interface design, far from being a cast in stone user specification, can be a tool that can demonstrate more succinctly the user’s goals and value from a system than words can.

Another reason I think it might work to produce really good user experiences, and I’m thankful to Arlen for this insight, is that it allows the design team to employ a type of set based design, where a number of options for the interface can be simultaneously explored at once, to create innovative designs, rather than the single simplest design that could possibly work. While this is a good practice for backend architectures, evolutionary design can only take a mediocre design to an OK design. To create compelling user experiences, you need to start from a good or great design and iterate to make it better.

This practice, taken with the other 12 practices that Jeff recommends can integrate more successfully with usability teams and create the kind of user interfaces that customers are now demanding.

Posted in Uncategorized | Tagged , , , | Leave a comment