Many agile methodologies require dramatic change to an organization during adoption. For instance, Scrum adoption often requires a complete reorganization of the development team, regardless of current structure or corporate culture. This can sometimes lead to dramatic success, but in far too many cases the result is chaos, thrashing and failure. For many organizations, the risk is too high, so they plan to adopt agile “tomorrow, when things aren’t so busy”. But tomorrow never comes.

There is another way.

In response to the high failure rates of agile adoptions, organizations of all sizes have sought another path – incremental improvement. And it’s working.
This presentation introduces the tools and techniques for incremental process improvement, why it works, and tips for adoption. But we will also talk about when it doesn’t work — because incremental change isn’t always the right fit.

To wrap up, we’ll walk through the organization and cultural patterns that lend themselves to incremental change, and those that lend themselves to radical change. You’ll walk away with an idea of where your organization fits, and what path to agile adoption that you should take.

Abstract extracted from: http://www.alm-summit.com/sessionsALM.aspx

I didn’t mention how I spent all those years pestering poor Keith, the organizer, to let me be a speaker at Summit.  “C’mon, just a 15-minute lightning session.  The public sector is interesting… no, really…”  He must have had a good laugh this summer when I told him I was moving to Northwest Cadence, me having no clue then that Northwest Cadence is a Platinum Sponsor of the entire Summit!  I think Keith might have had a better idea what was in store for me than I did!

So I arrived at this year’s Summit unsure what my new role and our Platinum Sponsorship would mean for me.  Keith already rolls out the red carpet for all attendees, so it’s not like I needed to be treated any more specially.

Interact!

The Summit really is as much about connecting with people—industry colleagues, thought leaders, and real development teams trying to solve real problems—as it is listening to lectures.  Northwest Cadence demands this of me, which I love, though I’m still trying to overcome feelings of guilt whenever I miss or multitask any part of a session…

It’s a huge thrill to find that some attendees remember me from last year.  One actually did a double-take: “Steven, she’s with you guys now?!”  Double win!

On Tuesday afternoon, the Summit rolled out its new concept, Open Spaces: self-organizing discussion groups on attendee-selected topics.  Martin, Steven and I dove into a big one: “Scrum or Kanban?”  We talk about this in the office all the time, and we give Coffee Talk webcasts on it, so I’m eager to expand my/our knowledge with insights from others.  Scrum.org was well-represented in the group, but I was surprised, and fascinated, to see Kanban take up the majority of the discussion time!  It seems that while a lot of teams have adopted Scrum, for one reason or another they may be looking to introduce Lean/Kanban thinking into their process as well.  2011 is perfect timing for this, as we’ll see later…

Kanban Is Buzzing

On Wednesday afternoon, our own Steven Borg delivered a session entitled “Questioning the Big Bang Theory: The Case for Incremental Change”.  Even though the title was tuned to be agnostic and accessible, Steven can’t outrun his reputation, so quite a few attendees greeted him with, “… and we can’t wait to see your Kanban session later!”

Figure: The kids back at the office had their fun with his goofy agenda image…

I got to work in advance with Steven to help craft his presentation, including playing with Prezi, an awesome, non-linear alternative to PowerPoint.  We had fun watching each other’s adorable little Prezi avatars wander around the screen as we co-edited online.

Steven’s an amazing speaker, by far one of the most engaging at the Summit, and I’m not just saying that because his company pays me.  (Pretty much reverse that causation arrow… but that’s another blog post.)  Check out the recorded sessions if you have any doubts about this.

I think there’s a need in our industry to address the question of incremental change, too: Scrum provides great, interconnected, proven tools right out of the box, but what if your management won’t give you a box?  Steven showed us how concepts from Kanban supported by specific techniques for followup, problem-solving and incremental actual change offer a good alternative.  Or a good supplement!

I was motivated by this and Tuesday’s Open Space to blog about what I see as a Kanban risk: Underpants Gnomes. Kanban helps you visualize an existing process, but does your team have the necessary mindset and skills to then identify problems correctly and fix them positively and productively?

Technical Reception

After hours on Wednesday, the Northwest Cadence operations crew came over and we set us up a cool sponsor booth and live demoing station.  We raffled a DIY Kanban Wall kit with the same supplies we used to create our own Kanban Wall at our office: magnetic primer, chalkboard paint, smudgeproof chalk markers, laminated dry-erase magnet cards, lots of fiddly magnetic bits, painting implements, dropcloths and a bucket.  We set up some other paint-themed decorations and threatened to put the newest ALM Consultant in the Ty-vek Sta-Puft Marshmallow Man paint suit… wait, I’m the newest ALM Consultant!  Help!

Our idea for Mini Coffee Talks with self-organizing topics didn’t quite take off as we’d hoped, though mostly for the very satisfying reason that attendees kept wandering over and striking up conversations and keeping all of us consultants busy all evening.  I played around with IntelliTrace at the demo station for a few minutes, which I don’t think constituted a demo because I think only Dan was watching; for the rest of the evening, about every 20 minutes or so I’d wander over to the laptop and put up a single provocative slide to see if I could get a conversation started.  One of my favorites, “ATDD: Because Customers Lie” was a crowd-pleaser, and I’m looking forward to building out that idea in a future full-length Coffee Talk.

Everything Scrum Is New Again

Several of our esteemed industry colleagues got into shape in 2011 and turned up at the Summit looking fit and trim.  Great job, guys!  This year, Scrum also finds itself right-sizing and focusing on essentials.  Our own Martin Hinshelwood summarizes the overall change in approach beautifully in his blog post Are you doing Scrum? Really?, authored during the Summit.

Figure: Don’t be too sad for it; it had a good run.

Perhaps the most jarring change for Processistas is the sudden and unexpected demise of Scrum But.

Is this the start of a kinder, gentler Scrum?  When I started working with Steven and Martin on our “Scrum vs. Kanban” webcasts, I joked that I wanted to move us away from “shootout at the OK Corral” and towards “Kum-Ba-Ya around the campfire”.  Who’s laughing now?  Scrum is newly open to modification and extension, so we’re replacing Scrum But with Scrum And!  Maybe now the process community can focus on helping teams find a the right mix of techniques that work for them.

The round-table format of the Thursday presentation by David Starr (now at Scrum.org, nice catch y’all) was nicely engaging, a good way to get folks up to speed on Scrum 2011 and address their specific questions, with Professional Scrum Trainers (including Martin) scattered throughout the room to support and keep things focused.

I’m totally reworking my “Scrum-damentals” webcast sessions coming up December 1 and December 15 on MSDN, so tune in there if you’d like to see what all this fuss is about!  Hopefully I will have figured it out by then.

Tools Still Rule

The focus of the Summit was further clarified this year with the split into an Application Lifecycle Management (process) track and an Agile Developer (practices) track, but it’s clear (as it is every year) that for this audience, tools rule: rooms filled up and Twitter traffic spiked any time a presenter on either track did a cool demo, especially around Dev11/vNext.

Post-Conference Workshop

Steven brought me in along with Martin to assist him in teaching Friday’s course, “Enterprise Management of the Software Process”.  They let me run the “Intro to Scrum” portion of the agenda, where I got to try out my new learnings and did a respectable job explaining the core framework and extensibility principles.

Nearly everyone in the room was already doing Scrum, and were eager to learn whatever we could share with them to help them move to the “high-performing” end of the bell curve.  In Thursday’s session, Steven had touched upon queuing theory and his Monte Carlo simulation spreadsheet—on Friday he expanded upon this idea to illustrate two key concepts:

1. Queues are a bigger problem than we generally recognize
2. Work in Process (WIP) limits significantly improve queuing

My favorite part was Martin and Steven’s live coin-flip queuing demo, which really made it understandable for the non-math-majors in attendance!

Wrap-Up

ALM Summit is by far my favorite conference, the one I used to fight every year at my old job to be able to attend.  It’s comical that I totally by accident (if you believe in accidents) ended up working for one of its Platinum Sponsors.  Now I’m graduating from audience member and #fangrrrl to an all-access backstage pass and… I wouldn’t say producer credits yet, more like a junior member of the stage crew.  This is a community I’m happy to be part of, and I hope Northwest Cadence and I can continue to grow as leaders in the process, practices and tools arena for years to come!

Introduction

Watching the performance of your TFS 2010 server is important. And having reports that show historical trending is very useful. Luckily, Grant Holliday, Microsoft Program Manager for Visual Studio Team Foundation Server, has two blog posts featuring some excellent report packs. Both sets of reports can be used against TFS 2010 (although one set requires some extensive modifications).

You can view the blog posts here:

• TFS Performance Report Pack
• TFS Administration Report Pack

The Performance Report Pack provides a lot of great information about the state of the TFS 2010 Farm, including historical trend data for both version control and work item operations. It is great for discovering, if you are experiencing intermittent performance problems. Originally, it was written for TFS 2008, but it can be upgraded to TFS 2010.

The TFS Administration Report Pack is a set of three reports that show data about the TFS Analysis Services cube and data warehouse.

The main issue with both of these report packs is that the instructions for creating the data sources for TFS 2010 are not included, or better said, the instructions are easy to figure out, but not specific enough to be completed trivially and with ease.

The following steps make creating the required SSRS data sources trivial.

Steps for Adding Data Sources

The report data source is needed by most of the RDLs that are provided with the report packs on Grant Holliday’s blog, and it is tied to the Tfs_Warehouse database. While the configuration data source is not used by all of the reports, it is still needed and is tied to the Tfs_Configuration database.

To add the data sources, you will want to go to your report server website with the following URL structure:

• http://<servername>/Reports

Personally, I opened an RDP session with my server and used http://localhost/Reports to access the SSRS website. From here you should see the SSRS Home page.

At the top of the page there is a ribbon of buttons with “New Data Source” being the second option. Click this button to start adding a new Data Source.

Figure 1: New Data Source button

We want to configure each data source with specific names to be sure that the reports in these packs will be able to connect to them without an issue. For the Tfs_Warehouse data source we want to fill out the new Data Source Form with the following information:

Figure 2: Report Data Source Settings :

• Name : Tfs2010ReportDS
• Connection String : Data Source = <TFSServer>;Initial Catalog=Tfs_Warehouse
• Credentials stored securely in report server checked
  • User Name : This should be whatever you use for your TFS reporting services (i.e. TFSReport)
  • Use as Windows credentials when connecting to the data source

Click okay, and the first data source will be created. To create the data source that is tied to the Tfs_Configuration database, click the “New Data Source” again, as done previously, and use the following configuration:

Figure 3: Configuration Data Source Settings

• Name : Tfs2010ConfigurationDS
• Connection string : Data Source=<TFSServer>;Initial Catalog=Tfs_Configuration
• Credentials stored securely in report server checked
  • User Name : This should be whatever you use for your TFS reporting services (i.e. TFSReport)
  • Use as Windows credentials when connecting to the data source

In these two screen shots I used the Administrator account for the data sources, but I want to make it clear that the account used for the TFS reporting services is the account that should be used for these data sources.

Once all is said and done, your SSRS Home page should have the two new data source listed with a “!New” tag sitting next to them.

Figure 4 : SSRS Home Page after the two data sources have been added

Conclusion

With these data sources added to the SSRS web site, getting the reports in the TFS Performance Report Pack and the TFS Administration Report Pack to work is just a matter of uploading them. Having these reports can add a great deal of value to your Kanban or Scrum process, and being able to quickly and quite easily set them up is a huge bonus.

-James Tupper

I love this about kanban – a simply, nearly trivial, change to the board and the kanban is now telling me a new story, and helping me visualize my work in a new, enlightening way. Read on for the details!

Time for a New Change

I took my original personal kanban board design from a pattern described on their website, http://personalkanban.com.  It had four basic states, Backlog, To Do, Today, and Done.  After about two weeks, I updated it to include date-specific columns for the upcoming week. Then I let it percolate.  It’s been unchanged for the last several months…  until last week.

Background:
A month ago one of our customers was struggling mightily with their Kanban implementation, and asked us to conduct an assessment. After asking a rather lengthy chain of ‘whys’, we identified a fairly substantial problem with the way their prioritization was conducted.  Their backlog was visible to the development team, and was ordered in priority order. (GOOD) However, after some observation (and questioning) it became clear that new work was nearly always urgently prioritized at the very top, and the remainder got pushed down. (BAD)  In other words, there backlog behaved more like a stack than a queue.  Now, responding to change is an important agile principle, yet when all new items are consistently placed right at the top, it makes little sense to do any forward planning if the only items that ever get worked on are the latest ones.  (This bears a far deeper discussion, but in a later post.)

Last week, while frustrated about my inability to accomplish my weekly goals, I decided to modify my personal kanban to track a new form of information – urgent tasks that appeared throughout the day vs. planned tasks which I had prioritized and planned earlier. 

In other words, I wanted to track how much of my week was Stack vs Queue.

Visualizing Planned vs Unplanned Work

So I modified my process to use 3 different color ‘stickies’ to track my work.

• RED : Items that go directly into my Today column. 
  • These items most likely pre-empting planned work, are considered Work In Process (WIP) and are given a start date.
• YELLOW : Items that go into my To Do column.
  • These state is my first Work In Process (WIP) state, and once an item enters this state it is assigned a Start date.
• GREEN : Items to go into my Backlog column. 
  • These items haven’t yet entered WIP, and do not have associated Start dates.

First week results

As you can see, my initial gut was correct, and the majority of work I did each week simply “came up” and had to be done urgently. Now, this is not necessarily a bad thing. Much of my day to day work (when I’m not working with a client) is being called into sales calls, creating proposals, working through deep technical problems with others on my team, and other very important work that is nearly impossible to plan for ahead of time. 

(Quick note: Some of the items you see in the backlog are ‘legacy’ yellow stickies.)

Next Steps

Despite the value of the urgent, unplanned work, I still have concerns. There is an awful lot of red in my Done column, and precious little green. And that seems to wrong.  My gut feel is that I’ll need to look into ways to fit more strategic (green) items into my weekly work.

I love how a simple change to my kanban can tell me a new story, one I haven’t yet decided how I’ll respond to. But, I’m using Plan-Do-Check-Act (PDCA) to improve, I’ll be able to have a baseline now for comparison during the Check phase!

I’m struggling with a concept from Toyota Kata, by Mike Rother. The way I’m reading it, teams of cross-functional individuals hide dysfunctions and can slow process improvement efforts. Or, to be precise, allowing cross-functional team members to assist others hides a potential improvement opportunity by limiting the pain of not having work balanced appropriately (heijunka).

Let me explain.

The Arguments from Toyota Kata

1×1 Flow

In Chapter 5, Mike talks about 1×1 flow (AKA single piece flow), whose purpose is to reveal dysfunctions or problems in the current process. He contrasts two manufacturing teams to illustrate.

In Example 1, Figure 5-6 in his book, the people are all working at their assembly stations (and there is some slack in the system), and when one person gets overwhelmed with work, a downstream employee who is starved for work will move to assist, thus increasing overall throughput. Now, this process is flexible, the employees can work around problems, and they can absorb any variation in the processes.

In Example 2, Figure 5-7 in his book, the people have no slack, and are matched to each. Now, if an operator experiences a problem, throughput immediately suffers, since there is no slack, and any problems, including issues such as variation in the process length, are apparent, and can be handled by process improvement efforts.

Analysis

The first process has a lot of flexibility, and allows the team to make production. However, “…at Toyota this sort of flexibility is considered negative, since problems go unresolved and the process gets into a non-improving, firefighting cycle.”

He then specifically addresses cross-functional teamwork as an issue. “To compensate for this fluctuation, the downstream operators naturally walk from one value stream to assist in another, rather than idly waiting… Of course, this workaround is not a process improvement, and although it is done with good intention, it introduces even more fluctuation into the value streams.” And, even more strongly worded: “At Toyota, such self-compensating flexibility in processes would strike fear in the hearts of managers… Such a mode of operation would not be allowed, and would be viewed as a failure to manage the process.”

Pull Systems (Kanban)

Chapter 5 also addresses pull systems such as Kanban. In Figure 5-13, he shows a Supplying Department with numerous machines, each of which can produce items for a machine in the Customer Department (the next step in the process). The important thing to note is that every machine on the left can produce an item for every machine on the right. In other words, these machines are purely “cross-functional” and can “fill in” for any other machine in the same department.

Next, the author recommends putting a kanban system between them. He states we need two pieces of information: 1) Where the parts associated with a kanban card are located, and 2) On what machines the parts associated with the kanban card should be produced. Number 1 is pretty clear – we need to be able to go find the pieces. But number 2 is challenging. Mike states we should specify which machine actually produces the part we need, since this “helps us to see what kanban in really about at Toyota.”

Analysis

He continues, and I’ll quote at length, “How do you think the supervisor will respond if we ask him to define what parts run on what machine? The supervisor is likely to object to someone taking away his flexibility to run the parts on whatever machine is available. Perhaps he will say something like, ‘If we are going to define what parts will run on what machine, and thereby reduce my ability to run items on any machine, then we better start improving the reliability of those machines.’ And so kanban has already started working for us.” This is illustrated in Figure 5-14, where the second pattern makes it “Easier-to-understand causes of problems”

Finally (last set of quotes, I promise): “If your purpose is ‘make production’ then the flexible system looks good because despite the existence of problems you can work around them and still make the numbers.” and “Flexible systems that autonomously bypass problems are by their nature nonimproving.”

My thoughts

This flies in the face of so much I’ve thought in the past that the past few days I haven’t been able to get it out of my mind. I’ve been going back and forth with Hakan Forss and Alan Shalloway for a while, but the 140 character limits are too constraining for actually fleshing out a thought.

Then, while doing some test process consulting with a local client, I ran across an example.

The Scrum team has a total of 7 people on the team, and are a cross functional (in the sense they have everyone necessary to build product) and the developers on the team are cross functional (in the sense they can work on tester tasks). The team has been successfully delivering value at the end of every Sprint. By all external Scrum measures they look good. However, in their retrospectives, they’ve been frustrated by the amount of testing-related work that the developer-focused team members are doing. Not surprisingly, they’ve been told that good Scrum teams work with each other to ensure delivery of working software at the end of the Sprint.

The team believed it was “under committing” to what could be delivered in a Sprint due to severe constraints in the capacity of team members focused on testing. Now, if that’s all the tested features they could deliver in a Sprint, then they were committing correctly. But we have a problem. Since the coding folks were helping out on the testing tasks, they couldn’t code as productively as they would have liked.

Question: “What if the developers couldn’t work on the tester’s tasks any longer” (ala Toyota Kata).

Breakthrough! We restructured the development process to allow each team to focus on their core competencies, while they will still be able to deliver tested, high quality code. We used a target condition, from Toyota Kata, to stimulate the creativity and come up with solutions.

So, in my first use of the “cross functional individuals can hide dysfunctions” thought pattern, I believe we made serious headway in a difficult problem. It provided a very useful lens.

Do we give up on Cross Functional Individuals?

No.  I don’t believe so. I believe it to be a very useful thought pattern, but software development is radically different from manufacturing.

• Variation in Software is High – Extreme variation exists among seemingly equivalently sized tasks. Task time variation of hundreds or thousands of percent is common in software development. This means that if we have a “balanced line” (heijunka) on AVERAGE, we will be out of balance the vast majority of the time. To put it in Theory of Constraints terms, the constraint would whipsaw around the team unpredictably. Without at least some “load balancing” we might identify a whole host of problems, but nearly all of them would be variation-related. Trying to solve for variation in software development is a fool’s errand, and would block discovery of more substantial issues.
• Strong Teams Perform Better – High performing teams are generally made up of people who assist one another and form strong personal bonds. Working together on a difficult task can bring two people together in a way that working separately (even if cooperatively) can. This one is a bit fuzzy for me, since strong teams are surely created in Toyota; but I still have a gut feel that teams in which people are willing to bail each other out creates more positive improvement than can otherwise be gained with a strict load balancing effort.

My bottom line – I will continue to encourage teams to work cross-functionally and assist one another, but will periodically use the “cross functional teams and individuals can hide dysfunctions” thought pattern for process improvement.

What am I missing?

Addendum:

In doing some research for this post, I re-read the new Scrum Guide (from Scrum.org), and noticed that there is no mention of individuals on a team acting cross-functionally. In fact, it only states “Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team.” Thus, it appears the team could , in formal Scrum, be made up of two testers, two developers, one SQL DBA and one build engineer, all of whom only focus on their own core competencies and do act as “cross-functional individuals” to assist one another. (I’m NOT saying this is a good idea, just saying it doesn’t appear to violate Scrum, which surprised me greatly.)

Did Ken Schwaber see this as a possible dysfunction already?

I’m doing some research for a newsletter article and blog post and am trying to understand cross-functional teams in Scrum.  From my prior understanding, one of the defining factors of cross-functional teams is that they are made up of “cross-functional” individuals, who can work on different types of problems.  For instance, in Scrum everyone is called a Developer if they are on the Team.  This is true whether or not they have deep skills in actual coding.  (reference: latest Scrum Guide on Scrum.org).  The benefit being that if the testing effort is threatening the sprint, then the people with software development skills can work with the team members with stronger test skills to complete the sprint on time.  This benefit is very clear and has been noted by multiple people, such as Don Reinertsen (Principles of Product Development Flow) and many, many others.  I even seem to remember learning about that benefit from my very first Scrum Master course. 

However, it appears I’ve made an assumption that is not necessarily true of Scrum, and I can’t find good references in the canonical Scrum literature (new versions) telling me that cross-functional individuals are encouraged (demanded?) as part of Scrum.  The Scrum Guide defines a cross functional team as “Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team.”  I can find nowhere in the guide that states that Scrum teams should be able to work in areas that are strengths of other team members.

So, the question again: Can a Scrum team be made up of two testers, two developers, one SQL DBA and a build engineer, each of whom ONLY do their own tasks and work as separate silos within the Team?

Note that I’m not asking if it’s a good idea, but whether it is OK in formal Scrum.  It has, in the past, seemed to me that it not a good idea.  However, I will argue in the upcoming newsletter article that cross-functional individuals on cross-functional teams may be hiding dysfunctions and slowing process improvement efforts.  (Based on some thoughts in  Toyota Kata, by Mike Rother.)

Thoughts?

First of all, I responded to Martin with a screenshot that I had completed what he asked, and got more than 75% on the Scrum Open Assessment.

Figure: 80% on Scrum Open Assessment

After seeing my passing grade, I quickly ran through the answers to see which ones I had gotten wrong. Question #9 caught my eye because I had thought for sure that the team was not supposed to be managed.

“[The Development Team] are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality”
– Scrum Guide 2011

Figure: Marking me my answer, “False”, as wrong to the statement : Scrum Master is a “management” position?

Quickly, I realized that there were other management-type questions on the exam I did a simple “Ctrl+F” to search for the word “manage” (as you can see by the highlighted text in the figures). After scanning past a few questions I found question #20:

Figure: Clearly stating that Management has NO role in Scrum (Correct Answer)

A Scrum Master is on the Scrum team, and, therefore, part of “Scrum”. Yet, I was correct when I marked the answer “Management has no role in Scrum.” This ambiguity/contradiction was not alone during my initial lead-in to the Scrum world. Currently, the current issue has been made known, and, hopefully, we will be able to fix the double-entendre of the word “management.”

In a strict world of Scrum you have a Product Backlog and when you begin a sprint you move the items that you are committing to into the Sprint Backlog and then you pull your work from there – almost like a Kanban system but not quite, because the Work In Progress (WIP) limits are at a higher level and in general it tracks work at a higher level than Kanban does as well as several other differences.

The major problem we continuously run into is the complexity of the network and the hardware involved in the work that we do. To add to the complexity is the fact that different teams (which we have no influence over) take longer to do work than we do and they are governed by a strict set of Service Level Agreements (SLA) which you will often find in large companies where some of the core work, such as server maintenance or data center maintenance, is subcontracted.

Scrum, combined with the team size gave us the perfect ability to hide our problems which was not a good thing. What would happen is that teams would run into a problem in, say, the development environment and set things in motion to solve the problem (opened a ticket with the server team) and would then move on to the QA environment. The problem would occur in the QA environment and then move to the Pre-Prod environment – all the while this problem still occurred. But because the team kept pulling items from their queue to work on, they were “busy” all of the time and reporting good progress – but not actually completing anything.

I should note that some of the user stories were straight technical stories – software being installed for instance to get various environments up and running.

The problem here was two-fold. The first is that the way the user stories were constructed, installing software and moving code from Dev to QA to Pre-Prod were all part of a single user story – it was just different parts of the requirement and Scrum doesn’t track down at the task level. The second part is that the “in progress” bucket can be huge – it is up to the practitioner to break the story down into a manageable level. So lo and behold we were building up a huge amount of technical debt that turned out to be fatal for this iteration. What happened versus what should have happened?

What happened?

First a team of 15+ people is too big for a 15 minute standup each morning. 15 people x approximately 3 minutes each = 45 minutes. That’s a bit outside of 15 minutes and our team is actually larger than 15 people. So what did we do?

Mistake #1

We eliminated the 15 minute standup meetings in favor of a once weekly team meeting.

There were other forces involved in this decision – at any large company there are going to be a lot of meetings and the team was suffering from “meeting fatigue”. As the Scrum Master I didn’t want to add to it and I couldn’t figure out how to keep the meetings to 15 minutes regardless. This, of course, led to the second problem.

Mistake #2

In a larger team meeting, people are concerned that they will be looked on negatively if they keep reporting problems. So they don’t – or they under-report the magnitude of the problem.

Our iterations are one month long. This took me two months of looking back at the data to realize. Once I figured it out, I committed mistake #3.

Mistake #3

Private conversations regarding the problems people are experiencing do not allow the team to focus their energies on the problem at hand – it becomes an individual firefighting experience.

We have a lot of very talented people on our team. By having one on one meetings with individuals who were having problems I was getting right back into the problem that mistake #1 was designed to solve – the number of meetings skyrocketed as I had to deal with a whole bunch of problems one on one. In addition, I wasn’t able to bring the knowledge of the entire team to bear on a problem – I had to schedule more meetings to do investigation instead of just having everyone pitch in at once.

To be honest, some problems – specifically those that rely on external forces – can only be solved by escalation to management. And this lead to Mistake #4.

Mistake #4

I didn’t recognize the negative impact of the groups culture – which is, they were not rewarded for bringing problems to light. The team members felt management didn’t care – that they just wanted the problem solved but they didn’t want to know about it.

I am not management – I never will be. But because of my role team members felt that reporting problems to me was the same as reporting them to management. Which they were highly reluctant to do. This lead to Mistake #5.

Mistake #5

The team members had enough work in their queue that they could simply move on to something else. By not updating their status correctly I had no visibility of this.

What they essentially did was to try to handle the problem on their own, reported that everything was okay and on track when in fact that was far from the truth. They kept hoping that things would come back on track which they never did because no effective intervention ever took place. This effectively let us hide waste. There was one more problem that came out of all of this.

Mistake #6

We didn’t recognize quickly enough that the handoffs between team members were difficult and not working well at all.

In Scrum, one person is generally responsible for a user story from beginning to end – there is a concept of ownership. We tried to do that – as the Scrum Master I had the ownership. Why not a Product Owner you might ask. Good question – the team was reporting to five product owners at the same time with approximately 8 different statements of work per month. We are a core solutions team so we provide many different solutions for different customers on the same infrastructure. The reason for individual team members not taking ownership is because there were many coordination’s that had to occur to get a single piece of work done because of the specialized skillsets required to get the work done (we recognize the need to grow the skillsets but that can’t be done overnight). Essentially there was no coordination or collaboration in the handoffs of work or even the scheduling for when work would be done.

Those are the big six mistakes that I feel, in retrospect, that I made as a scrum master with this particular team. So, what did we do about it and how did it work? I can’t tell you how it worked because this is a work in progress and this is the first month we are doing this but I’ll post back with a follow up.

Countermeasures we put in place

Solution #1 – Implement a Scrum of Scrums

The immediate step was to appoint two additional Scrum Masters and “break” the team up into three autonomous teams (that is, each team is self contained – the mix of resources is such that each team has someone with the specialized skills needed to work a particular technology or type of solution).

This was done so that the Scrum Masters could more effectively deal with problems since they were only overseeing a small number of team members. And oversee is too strong a word, the Scrum Masters did perform some work as well. This freed up my time to do some more work since I was now the Scrum Master for only 6 people (including myself). This immediately led to another quick solution…

Solution #2 – Reinstated the daily stand-ups

The smaller teams allowed each Scrum Master the ability to hold daily standups that actually last only 15 minutes.

The standups are four days a week plus one team meeting that lasts one hour. The Scrum Masters also have a once a week coordination standup meeting. We ask the same three questions but reserve the right to extend the meeting to coordinate resources to meet special demands.

Solution #3 – A “true” Kanban approach

Individuals are assigned only one requirement at a time – the other requirements are held in an iteration backlog and are assigned to the generic resource of “Product Manager”. We do not discuss these items with the team members at all during our iteration planning meeting.

This had a whole bunch of ramifications. The first is that we would not commit to a full iterations worth of work – we created a monthly “roadmap” which said, “these are our goals for the month which we will try to reach”. The upside to this approach is that our iteration planning meetings went from 7 hours to 2 hours. Nice. The downside to this approach is that our team is currently really unable to make a commitment and stick to it. We had not been doing it for the last year so this is really no change from the status quo but it leads to another benefit:

When a problem is encountered it is surfaced and dealt with in a 24 hour period. What do I mean by this? Well, since team members are only allowed to work on one item at a time (a WIP limit of 1 as it were) when something goes wrong and they cannot fix it themselves we (the Scrum Masters) either find out about it in the next standup meeting or the team member contacts the Scrum Master as soon as the problem is recognized and it can be elevated to management ASAP. Work halts until the problem is solved. We then capture the resolution to these issues and turn around and drive them back into the process.

Note that this is a work in progress and we’re still working out how to best drive the problem resolution back into the process so we avoid the problem in the future.

In addition, this alleviates some of the management role that I was playing because if team members do not escalate problems, they have to explain to their management why they were working on one tiny item with an estimate of 8 hours for a week. It also allows Scrum Masters, through empirical observation to detect problems earlier.

Did I mention that our entire team is virtual and spread out all over the US?

Solution #4 – Reward problems discovered

The last item is to celebrate when a problem is found – the earlier the better.

We are using TFS for our work and created a special area for internally created issues. We encourage team members to report issues with the process as they find them. We review these issues each iteration and take one to improve upon as part of our work structure. It remains to be seen how effective this will be but it’s a start.

Conclusion

I debated whether or not to share this experience and in the end decided that there must be other teams running into these problems. I’ve been doing this for 5 years now (stricter focus on process and methodology that is) and I knew all about these problems and yet I let the politics of the organization suck me right back into things that I have coached other teams for years on how to avoid. Talk about feeling dumb.

And I had tried other things along the way but kept running into the same problems because I could not trust the team to do things in the way they needed to be done. While I still have that problem, I was also part of the problem because I was not explicit enough in explaining to the team why we needed things done.

Hopefully, this post will help other people who might be in the same situation.

Scrum, the grand-daddy of Agile practices vs Kanban the challenger.  Come see Martin Hinshelwood (ALM MVP and Scrum proponent) and Steven Borg (ALM MVP and Kanban fan) will go head to head, mano-a-mano, wit against wit, to persuade you which is the correct approach for your agile adoption!

Come see the benefits and weaknesses of both as Martin and I fight it out!  Plus, you’ll get a chance to cheer for your side and vote for the winner! 

More information is available at out Events page where you can find the follow on sessions diving deeper into both Scrum and Kanban.  Or you can register for the Smackdown directly by clicking this link: Smackdown! 

Photo Credit: THQInsider, Flickr.com

Tom DeMarco is a smart man, and I love the book “Slack”, so I hesitate to disagree.  However, I believe DeMarco is looking at the organization through a very particular lens, once which misses some critical aspects.  When I look through a lean product development lens, I see several times where internal competition can act as “Slack”.

Let’s use a thought experiment.  Recall that since DeMarco is claiming his statement is universal, only one counterexample is necessary. 

Software manufacturer MyCo has two very different, but both high risk, approaches to solving a customer problem.  Unfortunately for MyCo, it’s not at all clear up front which of the approaches will be successful technically and/or successful at delivering the most value to the customer.  However, they have determined that being early to market will be very profitable (in other words, their “cost of delay” is very high).  One way to solve the problem, while not relying on internal competition, is for the company to allocate their resources to one of the approaches, and wait for the other one.  If the first one works out, great (although it may not be as optimal as the other approach).

Instead, if MyCo decides to examine both approaches, they are setting up an internal competition.  They have also provided a time buffer (i.e., slack) by exploring both options simultaneously.  If only one approach is successful, then they will have the successful approach.  If both approaches are successful, they can select the best one.  And if neither one is successful, they have quickly eliminated this possibility and can move onto other things.

Whether or not it makes sense to set up this internal competition depends on the cost of exploring the options and the cost of delay.  If the cost of delay is high (alternatively stated, if the benefits of being early to market are high) relative to the cost of exploring the options, then both should be explored simultaneously.

Thanks to @aJimHolmes and @alshalloway on Twitter for bringing up this topic, as well as Donald Reinertsen for providing the particular “lens” to look through.

UPDATE:  This is a common issue with technocrats – people who believe that having a smart person in charge of things can improve results over a marketplace (or goods, ideas, or whatever).  Just like DeMarco believes that smart managers should eliminate internal competition as wasteful, smart politicians often believe they should eliminate competition in the external marketplace as wasteful.  It’s so intellectually appealing, but is only a vanity.  F.A. Hayek expresses these concepts far better than I when he discusses the limitations of knowledge in society in “The Fatal Conceit”.  Although he talks in terms of entire economies, I believe these thoughts apply (although to a lesser extent) in smaller societal units like organizations.