The Complexity Trap, Part 1

I presented this topic at Mile High Agile 2012 under the title: Great Teams Keep It Simple.

“Simplicity–the art of maximizing the amount of work not done–is essential.”

– Agile Manifesto Principles

Agile teams and leaders tend to think of this principle in terms of reducing the complexity of the product being developed, from UI/UX flows to the back-end code. There is another area in which it is vital to focus on simplicity, however: the way we use various agile artifacts. Areas of complexity include:

• Backlogs
• Task boards
• Burndowns
• Individual “Velocities”
• Utilization tracking/measurement

Backlogs
The most obvious way backlogs become complex is when they contain too many detailed stories. I have seen backlogs that contained thousands and tens-of-thousands of stories. Such backlogs are unworkable, unmanageable, and wasteful.

Another, less obvious but more insidious way backlogs become complex is when they are sliced along functional layers, rather than across those layers. Like a cake made of wood, stories written within functional layers make the Product Backlog rigid and impenetrable. Functionally layered backlogs are rife with irreconcilable dependencies and integration nightmares.

Task Boards
Task boards generally become complex in two dimensions: work states and team assignment. In the former case, the task board develops many columns, each depicting an intermediate state of doneness for tasks or even stories. In the latter case, the task board gets cut into sections, one for each team member, with tasks and even stories falling into individual team-member domains, often during Sprint Planning. In extreme cases, I've seen both of these dimensions of complexity expressed on the same task board.












The usual result of complex task boards is unfinished work at the end of the Sprint, as depicted below:











Sprint Burndowns
The Sprint Burndown is an element of transparency, showing the inner workings of the Sprint for all the world to see - and for the team to use as an input to daily decisions. Sprint Burndowns also frequently become so complex that they are essentially unreadable, as in the example that follows, which tracks, among other things, actual hours expended, an inherently damaging metric.













Tracking Individual Velocities
One of the most insidious artifacts I've seen in use is the tracking of individual "velocities" within a team, the implication being that stories are written in such a way that only one person works on any given story. The damage this type of metric inflicts on a team is incredible and often difficult or even impossible to repair.











Symptoms of Complexity
Some of the symptoms of complex work structures, as indicated by complex artifacts include:

• People with nothing to do the last couple of days of each Sprint – usually “developers”
• People with nothing to do until the last couple of days of each Sprint – usually “testers”
• Gold-plated code
• Poor quality code
• Unfinished work most Sprints
• “We’ll test later”
• Internal team stovepipes that require hand offs
• Morale and motivation problems
• Lack of Teamwork

Complexity in agile artifacts creeps in, uninvited or intentionally, for a variety of reasons.

• Lack of team cross-functionality
• Lack of a dedicated team – resource pooling and matrixing people across teams
  
• Artifacts of thinking – habit
• Fear
• Lack of trust, both within the team and between the team and the broader organization
  

I often find that complexity results from teams' and organizations' attempts to find ways to adapt agile to their existing project management and organizational assumptions. Agile is all about changing the way people and organizations work, to move beyond organizational structures and assumptions that arose to serve a different purpose and way of working. Clinging those structures and assumptions, long after they have ceased to be effective, is a major impediment to improvement at every level, from individual teams to the organization as a whole.

Next time, let's look at the opposite of complexity - simplicity - and apply the Agile Manifesto principle that started us off in practice.

All for now....

...-.-

Visualizing Cross-functionality with a Team Spectrograph

Cross-functionality is a key characteristic of agile teams. The benefits of cross-functionality are well-known, so I won't go into that here. But how can you tell if your team is cross-functional? How can you help your team become more cross-functional? How can you tell if you're making progress? All good questions. Fortunately, there is an answer.

Cross-functionality within a team doesn't just happen, it has to be deliberately and thoughtfully nurtured. So let's live the principle of Transparency and make it visible! A tool that I have found highly effective is the Team Spectrograph. A spectrograph plots amplitude against a segment of the radio-frequency spectrum. We can do the same thing with team skills, that is, plot the skill levels team members possess (the amplitude) across the spectrum of skill sets the team needs to have.

Here's how it works. On a white board or tear sheet, draw a standard x-y graph. On the x-axis, list the skill sets the team needs in order to deliver the work it is being asked to do, each skill representing a tic mark along the x-axis. On the y-axis, draw evenly spaced tic marks from 1 to 10, with zero represented by the baseline of the graph. Then, have each team member self-assess his or her skill level on that one-to-ten scale across all of the skill sets depicted. Have each team member use a different color marker and voila! - you have a team spectrograph that captures your team's cross-functionality as of that moment in time.

The example above depicts a team that is well-balanced across the needed skill sets, but lacks cross-functionality. The independent, non-overlapping peaks represent skill silos within the team.
















This example depicts a team that is completely lacking the "Docs" skill set.

Using the Team Spectrograph to Grow Cross-functionality
Now that you can take a snapshot of team cross-functionality, you can take a new snapshot at a team Retrospective every three months, for example, to see progress and indicate areas where the team needs to focus on extending its cross-functionality. Using the first spectrograph above as a starting point, the following four depict the conscious development of team cross-functionality over the course of a year.

After three months...















After six months...















After nine months...















A year later...















Notice how all of the lines have come off the bottom of the graph indicating that every team member has at least some level of skill in each area. Notice also that the many skill areas have pegged the spectrograph. A side effect of transferring skills throughout a team is generally the enhancement of core competencies among team members. In order to teach someone else, we have to get better at what we already do best.

Team members can use their Team Spectrograph as a reminder to focus on techniques that build cross-functional skill sets, pair programming being the single most effective one I know of. The Team Spectrograph is also a reminder that cross-functionality doesn't just happen - teams grow and nurture their cross-functionality deliberately - one task at a time.

Another benefit of the Team Spectrograph is that it points out individual skills other team members were unaware of. Now that the full range of skills team members possess is visible, the team can take full advantage of its extant cross-functionality.

All for now....

...-.-



Updated:
I will be presenting this topic at the Atlanta Scrum Gathering, May 7-9! We'll have fun learning more about cross-functionality and building a real Team Spectrograph!

Scrum Gathering London Wrap-up

Just a few words about the Scrum Gathering in London, October 11-13, 2011. I was honored to be selected to present a session: Getting Beyond Yes: From Cooperation to Collaboration. This was the first opportunity I have had to present this particular session and I was truly humbled (and stoked!) by the extremely positive response from the 40+ attendees.

In this session, which appeared in the ScrumMaster/Coaching track, I explored the key differences between cooperation and active collaboration on Scrum teams using the Thomas-Kilmann Conflict Mode Instrument as a hook into the ways in which people respond to intra-team conflict. The punchline is that as teams move from Norming toward Performing on the Tuckman model, individual team members learn how to break out of defending fixed negotiating positions and instead move into what Jean Tabaka calls Constructive Disagreement, which is the essence of collaboration. Cooperation modes tend to follow the path of least resistance, whereas collaboration, with its inherent friction, leads to breakthrough innovation. It was a fun session with quite a bit of good discussion and problem solving. I appreciate everyone who attended for contributing to our shared success!

I was extremely fortunate to be scheduled in the first session time slot on Tuesday, so the rest of the week in London was low-stress and extremely fun. The sessions I attended were of generally high quality and the conversations were top flight.

This was my first-ever visit to London, so sight-seeing was definitely on the agenda after the conclusion of the conference! London is (no news to anyone who has been there) an amazing city with incredible history, wonderful museums, and interesting walking. Narrow sidewalks and fast-moving buses and taxis literally inches away added a little additional excitement to several city walks. And to top it all off, the weather was great most of the week!

If you've never attended a Scrum Gathering, Agile Alliance conference, or local/regional agile conference, I highly recommend the experience. Presenting, participating, meeting old friends and making new ones are just some of the many benefits.

All for now....

...-.-

The Burnout Chart

A little while ago I was talking with a Product Owner at a company just beginning its Scrum adventure. The topic of discussion was the Sprint burndown chart, its data points, and how to interpret the trend line indicated by those data points. The fact that the Sprint burndown is designed to serve as a planning tool for the team was not an issue. The Product Owner's concern was to ensure that the information radiated was interpreted appropriately by others in the organization, particularly those who might consider an upward spike in the burndown to be a sign that the team spent the day water skiing instead of working.

A teaching moment ensued and after a brief conversation and help from a colleague of the Product Owner, the purpose of the burndown was clear and agreement reached on using task hours remaining, among the alternatives I offered up, as the data point collected.

The discussion then turned to why one would use a burndown chart instead of tracking hours expended by the team in pursuit of the Sprint goal. Again, a teaching moment about the purpose of the chart, and then the insightful comment from the Product Owner that tracking hours expended would be plotted on the "Burnout Chart."

All joking aside, this strikes me as an interesting idea. Perhaps teams that are having difficulty working at a sustainable pace should use a Burnout Chart internally as a way of monitoring collective adherence to this vital agile principle. Perhaps teams in that situation could use the Burnout Chart to raise unsustainable pace as an organizational impediment.

Next time you notice that your team is showing signs of exhaustion, perhaps a Burnout Chart would be a useful way of determining - and radiating - the cause.

All for now....

...-.-

Why You Need an Outside Coach

As a coach called into an organization to do something very specific, say, help get teams over the hump on continuous deployment or TDD or ATDD or something like that, a conversation with the sponsor frequently goes something like this:

Sponsor: "We've been doing agile for (some number of) years now and we're extremely proud of how well we're doing."

Coach: "That's great! I'd love to learn from your experience while I'm here."

Sponsor: "Absolutely!"

A few days later, after working with the teams on that specific technical practice, it becomes painfully apparent that things are not as advertised:

• Teams have abandoned the Sprint Retrospective
• Teams consistently fail to deliver stories during the Sprint, comfortably allowing them to slide into the next Sprint
• Sprint Reviews have become stale and self-congratulatory because they are conducted inside the team fishbowl, without stakeholders or customers present
• Sprint planning meetings are chaotic and painful because teams are not engaging in backlog grooming or "Story Time" meetings to get ready for the next Sprint
• Sprint planning meetings are artificially abbreviated so as not to "waste" time, leading to failure to understand stories adequately and failure to deliver those stories during the Sprint
• Teams work in personal silos, with hand-offs and queuing delays holding up story completion
• Teams prefer information refrigerators to information radiators because transparency is too hard/scary/threatening
  

These and a myriad of other problems and dysfunctions are the all-too-common result of an insular corporate culture that lacks the spark of cross-pollination. Agile can quickly become stale, stagnant, or just plain smelly when organizations look exclusively inward. Allowing team members and other agile practitioners to attend conferences is a solid strategy to keep the flow of ideas from drying up. But at some point, you need to bring in an outside coach to freshen up the organization's perspective.

Okay, I can already hear the objections. Yes, I make my living providing agile coaching services. However, I wouldn't be in this line of work if I didn't believe fervently in both agile values and principles and the benefits of coaching.

An outside coach has some advantages that are very difficult to obtain internally. First off, an outside coach is a disinterested observer (disinterested does not mean "uninterested" - it means having no vested interest in any particular outcome, an honest broker) and can therefore recommend things that people tied into the organization would be unwilling or unable to broach. An accomplished outside coach also brings wide-ranging experience to the table. After a few years of active coaching, most of us have seen the gamut of issues and can leverage that experience to help organizations overcome most any impediment, even ones we've never seen before.

Finally, an outside coach can offer that breath of clear air, the source of vital cross-pollination that helps freshen up your agile practice, providing the boost your company needs to overcome organizational gravity or get off the current plateau and move forward.

So freshen up your approach - call a coach!

All for now....

...-.-

Proto-agile in the Time of Hair Bands

Join me now, as we journey back to those golden days of yesteryear.... Yes, we're traveling back in time to revisit the 1980s, the decade of Reagan and bands with Very Big Hair.

In 1987, I took a job as the one and only technical writer at a little start-up company called Colorado Memory Systems. The company made consumer tape drives to help ordinary people hang onto 40MB or so of vital data. Forty whole megabytes was a lot in those days, considering that most hard drives only held half that much.

Aside from the nostalgia of those innocent days of yore, an interesting thing happened at CMS. First off, when I started there all of us could fit in a single, not-very-large conference room. In addition, we had no QA department. As a bootstrap start-up, we couldn't afford the inefficiencies inherent in specialist silos. As the company grew, we still had no QA department. The upshot was that everyone tested, every day, including yours truly, the tech writer.

The developers ran builds every day, which was quite an accomplishment considering that a clean full build could take five hours. Before leaving for the day, everyone grabbed the latest build, plugged a test tape into the drive, and ran a test script that would use said tape to beat on the software - and the tape drive itself since we also made the drives - all night long. We tested error rates, recovery from data error, heroic retry data recovery, and on and on. Every night. For several years.

In my roles there, first as the one-and-only technical writer and later as manager of technical publications, I worked hard to write the user documentation iteratively and incrementally as the software and hardware were being built. The user docs served as our UX test lab: if a feature or procedure could not be described simply, the feature or procedure was either poorly designed or too complex. The whole idea was to make tape drives a consumer commodity. Software and hardware that was difficult to install or use simply wouldn't cut it. So early engagement with technical writers, beginning in the prototyping stage of both the hardware and software, was the norm. And feedback from technical writers in the form of the written user documentation and face-to-face conversation was highly effective in helping to improve the design of the hardware and software iteratively.

Buy the time I left CMS in the early 1990s to pursue yet more education, we had grown to over 200 employees and Grunge had replaced hair bands. But we still had no QA department. There were still daily builds. Everyone still tested every night. User documentation still provided vital feedback on hardware and software design.

Only now, in the 21st century can I put a name to what we were up to all those years ago. We were doing proto-agile. True, we did not release incrementally. We did not work in timeboxes. We did not have formal cross-functional teams. We did not test first then code. We did not consciously practice continuous improvement. Those practices were still locked in the future, scarcely a gleam in the early agilists' eyes. We simply all worked together to build the best product possible in what were essentially daily iterations. Feedback was face-to-face. Testing and user docs were done early and often.

It's no wonder I still have a soft spot for bands with Very Big Hair.

All for now....

...-.-

Why Stand during the Daily Scrum?

I've been asked this question surprisingly often in recent training classes and coaching engagements. The easy answer is that standing with your teammates for a few minutes every day is a part of Scrum.

"You'll have to do better than that...."

Okay, let's do better then. In my experience, teams that stand during the daily Scrum:

• Display a higher energy level
• Speak more directly and to the point, referring to defined tasks
• Are more willing to ask for help
  
• Engage their teammates rather than reporting to the ScrumMaster
• Are more likely to raise impediments
  
• Talk about 50% less, but convey twice as much meaning
• Leave the daily Scrum energized and ready to work
• Find the daily Scrum a vital part of their day
  

On the other hand, teams that sit during the daily Scrum:

• Display a lower energy level, both in the content of their discourse and in their body language
• Tend not to refer to defined tasks
• Get bogged down in reporting minutiae
  
• Tend to report to the ScrumMaster
• Are easily diverted off-topic
• Spend the entire meeting looking at mobiles/laptops
• Hold side conversations
• Rarely raise impediments
• Talk about twice as much, but convey far less meaning to their teammates
• Leave the daily Scrum bored and disengaged
• See the daily Scrum as useless and sometimes drop the practice entirely
  

These results are subjective, based solely on three years of observing Scrum teams in action. On the other hand, these observations are extremely consistent across teams, organizations, and industries.

I think the big difference between sitting and standing is the signal it sends that the daily Scrum is not just another corporate waste-of-time snooze-fest meeting. The daily Scrum is of, by, and for the team. The symbolism of standing in a closed circle also reinforces the rational and emotional concept of "team."

As with most of the Scrum/agile practices, there's more going here on than meets the eye. And just because something isn't obvious doesn't mean it can be safely ignored. So suspend disbelief and try standing up. It might just be the catalyst that helps your team re-discover its energy and focus.

All for now....

...-.-