Earlier this week I was listening to my normal podcasts during my commute. The latest podcast for This American Life was a story about the NUMMI plant. If you aren’t familiar with the NUMMI plant, this was a joint venture between Toyota and GM opened in 1984. Basically, Toyota wanted to start manufacturing in the US and wanted a partner for their first plant, and GM needed help making a quality small car. So NUMMI was the result. They took a plant that GM had recently closed and re-opened it using a lot of the same employees, but they setup the plant following the Toyota Production System. The podcast really examines these two different styles of management and talks about the differences the team based style of work used in the Toyota Production System and the traditional command and control style management typically used in the US automotive industry. NUMMI was very successful, however GM was not very successful at replicating this success to other facilities. As the podcast points out, this was largely due to the cultural changes required to fully implement the team based approach and “stop the line” mentality that is key to the Toyota Product System.
Having started my career at a manufacturing facility, I was familiar with the Toyota Production System and new it shared a lot in common with agile. However, listening to this podcast just resonated so much with a lot of the struggles when trying to transition to agile, it really made me realize just how similar these two efforts are. Ultimately, what GM was trying to do was switch from a heavily command and control based environment where jobs were very specialized and separate (remember we were dealing with the UAW) to a team based approach where decisions were delegated down to the team level, inventory was managed in a just-in-time fashion, team members were encouraged and expected to always be thinking of ways to improve and try those out, team members (including managers) should be helping each other out, and quality should be built in from the beginning. Sound familiar?
If you are going through or plan to go through an agile transformation, I’d encourage you to listen to the podcast. If you have struggled through an agile transformation, you should enjoy the podcast as well and find it all too familiar. The auto industry has struggled with this transformation for over 30 years and, as far as I know, still struggles with it today. Honestly, I’m not entirely sure how to interpret that. On one hand, they have made progress. In large part, they have seen that the Toyota Production System is a superior way to work. They have successfully implemented in some instances. These things should make similar things, like agile, an easier sell and more obvious. I believe they also had a few more hurdles to clear in their transformations than we face in the software world. I’m not aware of any software unions, generally speaking in software development we don’t have massive supplier networks to work with (no where near the extent the auto industry does anyway), and there aren’t physical factories that have to be redesigned and retooled (yes we have offices and those may need redesigned, but we aren’t talking assembly lines, machine tools, robots, etc). However, the fact that they have been at this for over 30 years and still struggle with it isn’t the most uplifting thought. Hopefully, at a minimum, we can look at this and learn some lessons. Thanks This American Life for the great podcast! Please go listen to it.
the real point is day-to day, we never estimated; there was zero value in it. We did capture actual data though using our system, which made predictability possible just as I mentioned above.
Source: When I’ve Skipped the Estimates… | Paul Boos’ Nimblicious – Making Agility Tasty
This is a good post from Paul Boos giving an example of when estimates were not necessary. He also gives some examples of ways that he has provided high level estimates in quick manner.
Paul also hints at another trick for budgeting…
I limited the WIP of projects going on at any one time, so that I could keep my team close to constant size
If you have a constant team, the budget is pretty simple. What’s the cost of your team? That’s the budget for the year. So as long as you can keep the flow of work consistent you can keep the budget consistent. The real question then becomes is there any large or out of the ordinary for the year.
I highly encourage you to read Paul’s full post to see all his examples.
Andrew had another good post over on Leading Agile, this one about whether you should estimate placeholder stories. I liked Andrew’s post as I’ve had this same discussion with several clients recently and I think Andrew did a good job of explaining the reasoning behind it. [click to continue…]
In a business that depends on collaboration, you should receive your bonus from your colleagues (not from your manager) with a peer-to-peer bonus system.
Source: The Peer-To-Peer Bonus System
This is a great article from Jurgen Appelo that describes a better way of distributing bonus money to employees. Annual reviews and managers deciding on bonuses only demotivates everyone. There are lots of articles that talk about this and lots of proof behind it. And let’s face it, we don’t really need all that proof, the vast majority of us experience it every year. This is one of the first articles I’ve seen that has given a concrete example of an alternative…and I love it! Here’s what I like about it… [click to continue…]
create nonthreatening experiments that give the team a taste of the success they’ll enjoy if they make the change
Source: An Experiment in Enlivening Stagnant Teams – HBR
I enjoyed this article from HBR for several reasons. First, how did they go about solving a problem? They performed an experiment over a time boxed period. Sound familiar? This is what agile teams and especially agile coaches should be doing with each retrospective and iteration. Coaches should be encouraging teams to try out new techniques and approaches to address recurring problems. If they don’t work, try something else the next time. Having that time box and proposing it as an experiment can be very helpful.
A second reason I enjoyed this article, it’s a good example of agile values outside of software development. This HR department is being agile. They are doing experiments in time boxes, reflecting on the results after the fact, and making adjustments.
Finally, I enjoyed the article simply because it resonated with me. I was once an intern in a similar environment. The intern program had been established already and they already saw the value, but there was a group of tenured employees and then the interns. Interns were given a lot of freedom on projects and were seen as a great source of ideas, energy, and hard work (especially since they didn’t have to attend a lot of the red tape type corporate meetings). They too often converted interns to full time employees and I was one of those as well. It was a great experience in my life and I’ve always promoted internship programs.
So head over to HBR (if you’ve used your 5 free article for the month already they currently have free memberships for a couple months) and read the full article. Then start thinking about what some of your most troublesome issues are at work and some non-threatening experiments you could try.
The image at the top of this post, “Experimentation”, is a derivative of “Keep Out Experiment In Progress” by Steve Jurvetson, used under CC BY. “Experimentation” is licensed under CC BY by Development Block, LLC.
One of Atlassian’s product managers recently published a blog post outlining how they do release planning (in Confluence of course, but could happen in any wiki/intranet tool). What I like about it is they do a good job of capturing the high level vision and gradually drilling down into the details, and they include the team the entire way. Often, especially in more “traditional” environments, the team has little to no visibility into the “why” behind a project or the high level plan. In this approach, the team and stakeholders not only have visibility of it but contribute to building it out and are able to give feedback along the way. I’ve done similar things to help build shared understanding and ownership and thought this was a good example to share. Thanks John!
You need to make sure everyone on your team – plus other stakeholders like marketing and support – understands what you’re trying to build, why you’re building it, how long you expect it to take, and how the project is tracking towards release.
Source: Atlassian Blogs
Photo “Mountains In The Distance” courtesy of Donna Block.
Last year I had a post called Mistakes: The Core of Agility. In this post I discussed the fact that being agile means we accept the fact that mistakes happen. We have to be willing and able to talk about our mistakes and learn from them. Making mistakes should not be discouraged. Mistakes can be seen as failure so we have to find ways to make failure acceptable and turn our failures into learning opportunities, not punishable events. When we punish them, they will still happen, but no one will want to take responsibility and talk about them, so likely no learning will occur.
There was a great post over on ThoughtWorks blog the other day that described a culture hack called “Failure Cake” that seems like a great way to make failure an acceptable occurrence. When failure does occur, the person or team responsible accepts ownership, then buys a cake for the team and brings it in. While everyone is enjoying some Failure Cake the team discusses the mistake, potential changes to make to avoid the mistake in the future, and everyone learns.
When you experience failure the best way to make it taste better is eating a slice of Failure Cake!
Source: Make Failure Taste Better With Failure Cake | ThoughtWorks
Of course, as with any culture change, it takes support from the top, so getting your leadership team to participate in the ritual is important. Check out the full article over at ThoughtWorks for more details.
The image at the top of this post, “FailureCake”, is a derivative of “thought that counts? <3” by Heather, used under CC BY. “The Importance of Visibility” is licensed under CC BY-SA by Development Block, LLC.
I don’t always follow the same story splitting approach when I need to split a story. It has become intuitive for me so I might not be able to write about everything I do or what goes through my mind or how I know.
Source: Story Splitting: Where Do I Start? -LeadingAgile
Splitting user stories is always a tough topic for new teams. If teams are used to working in tiers, then this is a completely different way of thinking for them. We are looking to split stories into thin slices, not complete a tier at a time. As Andrew hints at above, this is also a bit of an art form. It’s something you develop and get better at over time as you learn to look at the problems differently. In the mean time, you have to constantly challenge yourself and ask how can this be broken down further. I encourage you to check out his post for some good tips, also check out my previous posts on the same subject: How You’ll Probably Learn to Split Features, Breaking Down User Stories – When versus How.
There was a good post by Susanne Albinger recently that showed the importance of visibility. I’ve been a long proponent of big, visible boards. Task boards, burn downs, impediments, you name it. Electronic tools seem great, they let you have these boards even with distributed teams, however they just aren’t visible enough. It is very easy to come in to work, sit down, and get started on what you were working on yesterday without pulling up the board to look at. When you finish something you can move right on to what you think is next without validating that by looking at the board. It can be very easy to forget to update the status of a task or story because you’re not in the tool right then. However, when there is a big visible board staring back at you whenever you look up, whenever you go get more coffee or to the bathroom, you just can’t ignore that. Not only can’t you ignore it, but you know everyone else can see it too. Others can walk by and see the items and ask about them. If it’s not updated that could cause questions and confusion. So in my experience, big visible boards are kept much more up to date than tools, but this applies to more than just task boards and story status. Susanne gives us a good example of keeping track of whose turn it was to be the “watchdog”, the person that babysat the build and took care of broken builds and failing tests.
It was not clear to everyone whose turn it was to be the watchdog. Somebody had to come up with a schedule to identify who was next. As a result, we started a list on our SharePoint server, which contained a name for each week. Still, people tended to forget about their tasks or simply not check the list. We needed something else, something that couldn’t be missed and was a permanent reminder of the task.
Source: Watch the Dog – Susanne Albinger
The image at the top of this post, “The Importance of Visibility”, is a derivative of “Existential visibility” by Quinn Dombrowski, used under CC BY-SA. “The Importance of Visibility” is licensed under CC BY-SA by Development Block, LLC.
Since we celebrate the signing of the Declaration of Independence on the 4th of July, I thought it was a good time to look at another declaration related to the agile space. In 2005 a group of leaders in the agile space (Jim Highsmith, David Anderson, Mike Cohn, Christopher Avery, Todd Little, Pollyanna Pixton, Doug Decarlo, Donna Fitzgerald, and Lowell Lindstrom) got together to form what is now known as the Agile Leadership Network. They created the Declaration of Interdependence “to serve as guiding principles to employ Agile and adaptive approaches for linking people, projects and value.” [click to continue…]