Home » behaviour
Category Archives: behaviour
I’ve recently stumbled upon two blog posts that got me thinking about agile adoptions and why they might fail (not in a safe way).
First there was this post that I saw because it resonated with a colleague and he shared it.
I don’t know Guillaume and I’m sure he is a very nice guy, but the post struck me as from someone who didn’t understand the Agile Manifesto and was confusing it with the prescriptive guidance in the Scrum Guide or the guidance of The Lean Startup.
As I was reading these two posts, I started asking myself Why are these authors making these statements? Why are they observing these effects? The way that I’ve understood the Agile Manifesto and its intent, you shouldn’t see these effects, at least not for very long. It struck me though that this is a story that I hear over and over again.
Then I had a light bulb moment.
We often talk about an “Agile Buffet” as a set of tactics or practices we can pull from and use as best fits within our organization. I like this. As a passionate Kanban Method practitioner, the idea that we’ll continuously discover
problems opportunities for improvement and that we’d want to leverage past industrial learning is a core philosophy for me. But the Agile Manifesto is NOT a buffet. We should not pick and choose which of the values and principles that we will follow and aspire to. They are all necessary ways of thinking if we’re going to pull our industry out of the dark ages.
Now I am not suggesting we shouldn’t be finding the best way to, in context, live up to those values and principles. We should be very disciplined in What we pull from the Agile Buffet and When we pull the improvement. This is where a Kanban Method approach to continuous improvement is enormously beneficial. With a functioning kanban system, we have data that allows us to make informed, economically sound decisions about improvements and a mindset that we are going to improve incrementally and in an evolutionary manner. We are actually slaying a software development dragon with a 1-2 punch of Agile Manifesto thinking and Kanban Method thinking. We’ve got something guiding us towards what a successful software development team would behave like (Agile Manifesto) and we’ve got something showing us how to get to that goal in a humane, intelligent, and economic manner (Kanban Method).
I would like to encourage you to go read the Agile Manifesto again and to go read about The Kanban Method. They won’t tell you how to do things, but they are telling you what you should aspire to do. Now with that in mind, go and look at the Agile Buffet. Read the Scrum Guide. Read the kanban blue book as well as look at case studies from teams that have used the Kanban Method. This is your buffet of tactics that can help you solve your problems. Start pulling from this buffet of industrial learning. Develop a capability to understand what works for you and perhaps more importantly what doesn’t.
But please remember, these value systems are not a buffet and you don’t get to pick and choose from the values and principles they provide.
Part 2 of my Exploration of Estimation
In part 1, I posed the question of Why are you estimating! I hope that you thought about it and may have found an answer or two.
The next question I’d love for you to think about is What are you estimating?
I was just in a meeting that was discussing a RFP for a client. This is pretty common in the consulting industry where we see a Request For Proposal and in that, we need to define the scope of work that we can address, align our skills and services to deliver that scope of work and then provide an estimated cost for that service. Seems kind of normal. But then we are also sometimes required to provide an estimated calendar duration for the project. So in essence, we are being asked to provide 2 estimates. We then present our guess (educated) at how much work needs to be done, and here is our guess (educated) about how long it will take the team to execute on that vision.
So when the developers were being asked to provide estimates to the work in the RFP, what do you think were they estimating?
I haven’t had a chance to ask them yet, but based on my experience (as both a developer and a person being asked to provide project duration estimate), the development team is probably estimating effort and not duration.
So who estimates duration then? How do we get duration from effort? And if we stacking a guess (how fast we deliver) on top of a guess (effort), are we getting a meaningful expected duration value?
If you go back to my rant on estimation (which I will reference often in this exploration series) you will see how most organizations, in my experience, do mental and mathematic gymnastics to come up with an expected duration value.
My belief is that we are not getting a useful duration value. But everyone treats it as useful, starts building elaborate project plans and organizational activities around this duration value, and then we are all shocked when we have to change request the project, drop scope, or scramble like crazy (and usually with questionable quality) in the latter half of the project when it becomes painfully obvious that we’re not going to make our original duration estimate. Either way, the initial setting of expectations based on the layer of several guesses seems to be a Bad Thing™.
So I’ll leave you with this final question, what are you estimating?
p.s. I will explore better ways soon! Just bear with me for a bit longer!
I was recently delivering some Kanban training at Yahoo! to a great group of people who were all struggling with many of the same problems we all deal with. Overburdening, long lead times for features and quality challenges, all of which exacerbate each other! Almost all of these people described having been on previous process improvement initiatives. Actually, in some cases, they described being in a non-stop process change initiative. And almost all of them were fatigued by all of the process change initiatives and were very weary of this new “Kanban Method” thing that they were doing.
This seems to be a very common problem that I experience. None of the prescriptive methodologies are solving the underlying problems, organizations are jumping from one prescriptive approach to another and employees are getting tired of it.
The fact that the Kanban Method really isn’t like this is one of the things that has drawn me to it. Let’s revisit the first of the 4 Kanban Method values.
Start with what you do now
Straight from Wikipedia – The Kanban method does not prescribe a specific set of roles or process steps. There is no such thing as the Kanban software development process or the Kanban project management method. The Kanban method starts with the roles and processes you have and stimulates continuous, incremental and evolutionary changes to your system.
This is a central tenant of any LKU Kanban professionals approach to teaching or coaching an organization with The Kanban Method. How can you suggest changes if you don’t know what the problems are? How can you expect a change to succeed without understanding the capabilities of the people within the organization?
When the people are Yahoo! were presented with this first value, they were able to almost immediately relax. We started to hear things like
You mean we don’t have do do anything different?
We can use some of these concepts and ideas within our current process.
Both of which are absolutely true and it is important that people understand this when it comes to starting a Kanban Method implementation.
We then present people with the remainder of the values, which are:
- Agree to pursue incremental, evolutionary change
- The organization (or team) must agree that continuous, incremental and evolutionary change is the way to make system improvements and make them stick. Sweeping changes may seem more effective but more often than not fail due to resistance and fear in the organization. The Kanban Method encourages continuous small incremental and evolutionary changes to your current system.
- Respect the current process, roles, responsibilities & titles
- It is likely that the organization currently has some elements that work acceptably and are worth preserving. We must also seek to drive out fear in order to facilitate future change. By agreeing to respect current roles, responsibilities and job titles we eliminate initial fears. This should enable us to gain broader support for our Kanban Method initiative. Perhaps presenting the Kanban Method against an alternative more sweeping approach that would lead to changes in titles, roles, responsibilities and perhaps the wholesale removal of certain positions will help individuals to realize the benefits.
- Leadership at all levels
- Acts of leadership at all levels in the organization from individual contributors to senior management should be encouraged.
All of which suggest that we do nothing but create an environment that will be supportive of the people who will be finding opportunities to change their processes. That’s it! You’ve now started a Kanban Method implementation, which has often been described as an intent more than a prescriptive, concrete set of things that you have to do.
At Yahoo!, after we had presented everyone with a new approach to thinking about how to approach their problems, we did start to give them some high-level tactics which they could apply when they were ready.
Over the course of the next couple days, we then showed them examples of how they could get more information about how they worked (Core Practices in the Kanban Method). And at no time did we tell them that they had to do any of them, but we described the benefits and limitations of these tactics and by the end of the 2 days of training, most everyone had discovered something valuable and told us they’d be trying to use some of these things in their teams right away. We didn’t know which of the tactics that these people would be trying, but we were encouraged that they felt empowered to start trying to use them at their own pace.
In a landscape of teams and organizations getting tired of process change initiatives, it was very rewarding and encouraging to find a group that when presented with The Kanban Method, were excited at the new way of thinking and that they weren’t going to be forced to do something. They were very excited that they would discover what their problems really were and then they would plan out their own changes to the process.
I don’t think I can fully communicate the value of co-location.
Any time I have been asked to help a company in recent years, the engagements have started out with an assessment. I don’t believe that I can provide sound advice unless I understand what the problems are and what the organization’s capabilities are.
One problem that EVERYONE has had so far is the absence of an effective place for their teams to work. Software development is a highly creative endeavor that requires (usually) a significant amount of collaboration between teammates and it constantly surprises me how organizations build terrible places for teams to try and achieve this!
When we started out with the client whom all of these Success Factor posts are about, the development team was spread out across ½ of a floor in an office tower and there were 2 members in a different city. Check out my hand-scribbled floor map with the initial, planned layout of the team members.
This is actually not bad compared to many companies I have observed, but this is far from optimal. The deficiencies that aren’t obvious from this floor map include:
- No team-specific collaboration space. Had to book meeting rooms and hope one was available.
- The Devs and PM have no whiteboard space. They are in cubicles.
- The BA, TW (Technical Writer) and CSM (ScrumMaster) were packed into a large office with minimal whiteboard space.
- PO (Product Owner) and HW (Hardware guy) were alone in their offices.
- There was no place to have daily stand-up meetings or to have our card wall up where everyone could see it.
- The sponsor was on the opposite side of the building.
For a team that is intending to collaborate frequently and intensely, this is a very poor setup. Our sponsor was spending in excess of $100k/month on the team in that room and he wanted to make sure we had every advantage to maximize that cost. So before we even kicked off the project, we made a rather bold request to have a board room near the sponsor converted into a team room. And our request was granted!! The facilities people were a little scared that we’d damage the boardroom table that was in there, so they had that taken out quickly, but the resulting floor plan looked like this:
Now we were excited! We had a room that could hold everyone. There was room for everyone but the PM and HW guy, due to the nature of their roles, didn’t need to participate as intensely as the rest of us, so they maintained their offices. And since our PO was also maintaining some business workload, she maintained her office as well. But all three team members attended all the meetings that we had in the team room and would often drop in to see how things were going. Let’s take a look at the team room.
I have to say, this is the best team room I’ve ever had the pleasure of working in. We had wall-to-wall whiteboards on the West and South walls, and the North and East walls where covered with large PostIt notes. The SE corner of the room had a projector screen and the projector sat on the SE corner of the team table. The computer on the East wall ran Skype and TeamPulse, the Agile Project Management Tool that we used on a daily basis (from Telerik). The room had a Skype account that was always logged in and you could call up that account and it would always auto-answer with video and put the caller on the projector. There were two microphones in the middle of the big table that would allow everyone to talk from where they were sitting with whomever called in.
I can’t say enough about the sheer wall space in this room. It was fantastic. On the wall-to-wall whiteboards, we had everything from architectural diagrams, to class diagrams, server layouts to retrospective results. We had everything on those whiteboards and they would be able to stay up for as long as needed for the team. We would write our retrospective notes up there, and leave them for the entire next sprint. Then the that sprint’s retrospective notes we be put up, and compared, and discussed. Then the former sprint’s notes would be erased. We had a constant rolling reminder of how important continuous improvement was to us.
The PostIt notes were used to keep less volatile things like our value statements right up in front of us. Also, team policies like our Definitions of Done, or our Prioritization logic where up there for everyone to see. There was never any doubt about how we wanted to work when you were in the team room.
We were creating a mobile system that included on-board tablets in trucks and we had our QA station right there behind our QA professional team mate, our PO and our BA! They could check specs, and then turn around and try it out right there in the QA environment. And if there was ever a problem, the developers could (and usually would) hear about it right away. That was one great aspect of our room that allowed our quality process become pervasive of everything that we did in that room.
I can tell you about a time that our QA lead was working on a test script in Microsoft Test Manager. Then he turned and tried the test step on the tablet and discovered a bug for a feature that was in the iteration. He called the developer over, who saw the defect right away. The QA lead logged the bug and the developer, whom had luckily just finished up a task, was able to pick up the bug and fix it right away. Our QA process was such that we could fix a bug, submit the code, all the automated quality checking mechanisms would run and then we could push the passed build up to the QA tablet where the bug had been fixed. In this particular case, the whole process took less than 1 hr. Discovered, Logged, Fixed, Built, Deployed, Re-tested, Passed. It is very rare for me to see a team perform this well.
But I totally believe that a big contributor is the team room that we’ve built for this team. Every team member feels the others pain when something doesn’t go right. This causes us to behave differently. Less selfishly and with a much more holistic approach to building the software solution.
And that was a known feature. The benefits of having the Product Owner, Business Analyst and Sponsor all within 20 feet of the developers is unbelievable. When anyone has a question about a feature or an idea that we’re trying to make real, the entire stack of business-focused people are right there, immediately available to answer the question. The only time that this team ever builds the wrong thing is when we are building something for someone who isn’t in the room. And you can bet that we escalate that immediately to our sponsor. Because he is 15 feet away.
And he just drops in all the time!! If he has a problem, he tells us. If he is curious how we are doing, it pokes his head in. He will see us working on a problem with our process and lend a hand if he can. And you can bet that this closeness has made the team much more aware of his concerns and challenges. It never feels like Big Brother is watching because there is so much transparency on the team that it is always about trust and helping to get the job done.
I could probably go on and on about all the benefits of this team room but I’ll wrap it up for the moment and leave the rest to your imagination so that you can think about what the benefits of this team room would do for your team.
I was recently at the Kanban Leadership Retreat in San Diego, hanging out with a bunch of great people from the community and talking all about Kanban for three days.
This is an un-conference format event so we end up talking about whatever the group is interested in talking about, and one of the best sessions that we had (amongst a group of great sessions) was a session on Little’s Law that was hosted by Dan Vacanti (@danvacanti). Dan has been talking about Little’s Law at conferences for the last few months and the group was really interested in hearing this presentation as well as the interactive questions and answer that would happen throughout. It was during the interactive part of the session that “it” finally clicked for me!
Up until now, I didn’t understand why I would need to use Little’s law. I don’t want to use this blog post to describe Little’s Law and besides, Daniel’s presentation does an excellent job of that.
I’m really dumbing this down but in short (Sorry Dan), Little’s Law provides two things of interest for us Kanban practitioners:
1. allows us to derive one of three important Kanban metrics when any two of them are available to use in the calculation
2. allows us to understand/predict the impact of changes on one of those values to the other two
On the first point, for people running their work in kanban systems, normally all of the values are available if you’re managing your work well enough. Approx. Avg. Lead-time, Avg. Work In Progress, Avg. Throughput are relatively easily tracked or counted, and they can all be seen in a Cumulative Flow Diagram. Given I can observe all three in our system; I don’t need Little’s Law to help with that.
Note* – For planning purposes, we can use this relationship to understand what numbers
we might need in the future. Eg. Calculating required WIP based on an anticipated throughput and a proven capability (lead time) to establish resourcing levels
The second point is really interesting to us but is also where we stumble upon the gotcha and the false knowledge that often occurs on teams when they are using Little’s Law. It was in the interactive session that I finally had my epiphany around this second point! It isn’t (usually) about calculating the missing number or predicting changes in the numbers. It is about ensuring that you CAN use Little’s Law at all!! That’s the tricky part and in my opinion, the really powerful thing I learned at KLRUS.
See, in order to use Little’s Law and have it work as you’d expect, there are a number of really important assumptions that have to be true before you can use Little’s Law and it is in making these assumptions true in our kanban systems that we achieve the true benefit!
The assumptions are (for the period of time that is under observation):
- All measurement units are consistent
- Conservation of Flow which assumes
- Average Arrival Rate == Average Departure Rate
- All work that enters the system flows through to completion and exits
- System is “stable”
- The average age of WIP is neither increasing or decreasing
- The total amount of WIP is roughly the same at the beginning and at the end
All Measurement Units are Consistent
This one is relatively easy. If you’re measuring in weeks for Throughput, your Lead time should be in weeks. If your WIP is a User Story, your throughput is in User Story. We can’t have WIP as User story and Throughput as Tasks. We can’t have Throughput as User Story/week and Lead Time as User Story/day.
Average Arrival Rate (AAR) == Average Departure Rate (ADR)
This one is a bit trickier, but not too bad. One of the assumptions required, as described by Dr. Little, is Conservation of Flow and this metric is one of the ways that we measure this in Kanban. And the tactic we use to manipulate this situation is our WIP limits. If we only accept new work into our system at the same rate that work leaves our system, we are stable enough for Little’s Law to work.
All Work That Enters the System Leaves the System
Work that enters our system and doesn’t exit in a predictable fashion will disrupt the Conservation of Flow. AAR and ADR can’t be equal if this happens frequently in the system. We do have to watch out for work being “created” within the system that could mask abnormal termination of work within the system.
Average Age of WIP is Constant
Little’s Law also requires a “Stable System”, which I’m not going to explore deeply in this article. One of the two metrics that we can use from our kanban system though to determine if our system is stable is the average age of WIP in the system. Over the period of time being observed, we want this average to be constant.
Total WIP at Beginning and End of Time Period are the Same
The second metric we use to determine system stability is WIP totals at the beginning and end of the time period under observation. If our WIP is trending up or down, we do not have a stable system and predictions that we get from Little’s Law will be suspect.
So what does this all mean…
So we have a law that we want to use, but in order to use it, we have to fulfill the required assumptions for the law to work. The required assumptions are going to cause us to create specific and explicit policies that will describe how our teams behave. The effects of these policies are varied, but you will see improvements in prioritization and pulling of work, queuing, swarming, workflow/system design, and WIP limits just to name a few in order to effectively strive to satisfy the assumptions.
The power of Little’s Law to Kanban teams is not its ability to predict WIP, Thoughput or Leadtime. The true power lies in its ability to influence team behavior with its underlying assumptions.
When Little’s Law is properly understood by Kanban teams, it will encourage those teams to strive to satisfy the Law’s assumptions which will result in improved predictability and a kanban system that can be “tweaked” to achieve whatever goal is required at the time.
Queues are all around us. Policies are everywhere.
Can we use the two together in a simple fashion to create business value?
Note* – Once you get really interested in Kanban, these are the kinds of observations and questions
that just randomly pop into your head, so beware. 😀
I was sitting on a plane and luckily had a window seat and I was watching the baggage handlers loading the luggage onto the plane. They were counting the bags and starting to load them onto the plane and I looked away for a bit. After a few minutes, I looked back and notice they were almost done and that is when I noticed the priority baggage tag on the last bags being loaded. This is where kanban took over my brain.
Could a simple policy that was implemented by baggage handlers and a Last In – First Out (LIFO) queuing technique manage the priority baggage solution? It seemed to me that this would be a simple tactic to provide a value-add service to customers that they might pay for.
I’m sure it would be a little bit more involved than that (bag check tagging bags, people loading the conveyer belts that take luggage the last mile would need to use a FIFO approach) but basically with a simple policy change (it would have to be an explicit policy) and an understanding of how queues work, the airlines have created business value out of thin air!
Are there any simple policies or queues that you could use to create business value for your organization?