Dispelling common misconceptions in Lean, Kanban and Scrum
Posted on 17. Nov, 2012 by ger in Agile, New Ways to Work, Scrum
Happiness Door Scrum Training Dublin
They say teaching is the best way to learn something. Recently, I delivered a Scrum training course for a multinational company in Dublin. Afterwards I did some reading to followup on some of the questions that came up. This reading lead me to some interesting new thinking on Scrum, Lean, Agile and even running training courses. It looks like many people have common misconceptions about how Kanban and Scrum fit together.
Some background
Scrum is one of the agile project management techniques that can make your team far more productive. Most of the time I’m CTO of Goshido (cloud software for project communication). Goshido is inspired in part by some of the concepts in Scrum. Some of our customers ask for training in agile project management and Scrum in particular. Our Scrum training is unique because I am still a practicing software developer and project manager, not a Scrum-trainer who delivers training every week.
Lean is a process improvement discipline that software development and startup companies.
Kanban is one of the Lean tools, originally a card or a box used in manufacturing to signal depletion of product, parts, or inventory. It is a way to “pull” work through a system.
Overlapping phases & organizing by project
The company I was training has structured the organization based on roles and skills rather than projects. The analysts are in one team, the UX people another, the developers and testers yet another, and operations another. During the project there’s a handover from one team to another. One of the principles of Scrum is to organize teams around the work that needs to be done for a customer, to mix the disciplines together with overlapping phases. Dustin Curtis tells a great story about the magic of Penn and Teller to illustrate the point that:
- Assembly lines work fantastically well for raw assembly, but they suck the life out of creative people.
Getting feedback during training
During each training day I asked people to provide anonymous feedback both half way through and at the end of the day. I applied Jurgen Appelo’s happiness door technique. I got great feedback from the attendees and was able to make adjustments both during the day and for subsequent days to make the training more relevant and valuable to the people attending.
Kaizen, retrospectives and continuous improvement
One of the technical leads was concerned about the business focus of the product backlog. How would he get technical tasks like a transition to github into the backlog? He knew this would boost the productivity of the software team but what if the product owner didn’t feel the same way?
Conversely, I’ve seen situations in other companies where technical leads have refactored parts of a system without concern for the business priorities. This in turn lead to a surprise then an overreaction by senior management who as a consequence put unnecessary controls in place to enforce visibility.
In my experience, Scrum retrospectives pay big dividends at the end of each sprint but it’s easy to let them slide. In the post “Getting Lean with Scrum”, Christine Hegarty describes how you can add a simple process to retrospectives.
She suggests capturing a single kaizen in each retrospective to be added to the next Sprint backlog as a task. I think it’s a great idea, and could balance the needs of continuous improvement and business priorities while making retrospectives more actionable.
Misconceptions about Lean and Kanban
While reading Christine’s post I also spotted a guest post by Jim Coplien describing Kanban, Lean and Scrum. I remember Jim from the early days of the software patterns movement. He wrote a pattern language for software organizations. Jim is a co-author of the recent book Lean Software Architecture. In the blog post, he clarifies some of the many misconceptions of Kanban and it’s goals.
- The challenge is to develop a learning organization that will find ways to reduce the number of kanban and thereby reduce and finally eliminate the inventory buffer. Remember: the kanban is an organized system of inventory buffers and, according to Ohno, inventory is waste…
He’s also concerned it’s been missappropriated in software development.
- Kanban applies to repetitive work — building the same item again and again… Not everything can be replenished based on a pull system; some things must be scheduled… That is what software is like: We rarely build the same thing again and again.
The ideal Scrum team “does a little analysis, a little design, a little building, and a little testing all at once in very short cycles”. While Kanban can be a good fit for teams that view work as firefighting…
- A good Scrum team automatically enjoys the provisions of kanban when practicing one-piece continuous flow. It is a built-in way to limit work in progress while encouraging teamwork. It gives team members time-boxed autonomy to carry out their plans while enabling them to better meet their planned forecast. Such maturity may be a foundation for later addition of techniques like kanban…
Learn more
Try Goshido, our collaboration & project management platform. Goshido is so flexible it can be used for Scrum, Lean and projects with traditional work-breakdown plans. Some of our customers do all three together. They map out a long term plan using Gannt charts then each team runs sub-projects as Scrum-Sprints.
Enterprise 2.0: What’s Next for Social Business?
Posted on 30. Jun, 2011 by tom in New Ways to Work
Would you like some process with your social business? And just to be clear before we dive in, I come not to bury the E 2.0 movement, but rather to suggest where we need to do more.
Ger and I spent some time last week at the Enterprise 2.0 conference in Boston, and we had an extremely productive three days. The energy was great, and candidly, the Hynes was full of smart people who are passionate about making their organizations and themselves more productive and better able to take action on the information with which we’re surrounded today.
If you want a recap of the conference, please visit the blog of Cecil Dijoux. You won’t find a better recap – thank you Cecil and thanks to all who tweeted out his work. While there is plenty of skepticism surrounding the E2.0 movement, Cecil’s summary provides some real data points that indicate a real and grounded revolution.
Please remember this positive recap as you read on. Again, I’m not here to bury E 2.0, but I do think some important issues are still barely being surfaced. Namely, there’s such a focus on information – wikis, chats, document repositories, social media listening and data – that we sometimes forget that we actually have work to do. We have tasks, goals and objectives, and deliverables owed to our colleagues, our partners, and our customers.
This is not a technology challenge. In fact, one exhibiting vendor’s “social dashboard” looked like the modular (“widgets” anyone?) web dashboards we were offering consumers in 1996.
This is not a category challenge. The issue isn’t whether the focus needs to be aimed at CRM, KM, ECM, etc. Work today requires cross-functional dependencies more than ever, so a premium on communication and adaptive work processes is by definition critical. Denis Pombriant had a nice posting last week that touched on this issue.
I believe we have a perception challenge. There’s still a gulf between the tools and data we have at our disposal right now, and the processes by which organizations and people are going to use those tools and data. IBM or Oracle saying that they have social business covered through the use of repurposed command and control tools doesn’t mean that they do. And saying that we’re going to self organize and ignore structure and process isn’t going to work either.
It’s our humble view here at Goshido that we need a sharper focus on doing. And one way to sharpen this focus is to think about how we can make guided collaboration a reality. We need to be more agile too. Not agile with a capital “A” and a manifesto, but agile as it’s defined in the dictionary.
Enterprise 2.0 is here to stay, but we have a lot of work to do. I guess that’s not a bad thing, right?!
Try Goshido, a new cloud-platform, which helps people: focus, communicate, and do their best work. Goshido applies new principles for how work can be organized; the perfect blend of Agile, Lean, Productivity and Attention Management.
Organization Structure and Working
Posted on 17. Feb, 2011 by tom in New Ways to Work
We talk a lot at Goshido about new ways of working. And not only do we talk about what might be considered best practices – we actually put many of these concepts to the test every day in both our activities and our product development efforts. With this in mind, two blog postings last week caught my eye on the themes of organization structure and getting work done.
The first posting was actually a rather lengthy and thought-provoking article by Dave Gray of XPLANE ⎟ Dachis Group. Titled The Connected Company, Dave posits some well-considered arguments comparing long-lived companies to cities, which are in turn a metaphor for complex organisms. I’m a firm believer that building and maintaining a company’s distinct culture is step one in building a successful enterprise. Dave provides some much-appreciated depth on this topic.
The second posting focuses on Agile, and the challenges large development organizations face when it comes to release planning. While I’m probably not qualified to state that Release Planning is Evil, I’m enough of a common sense guy to buy into Erik Huddleston’s notion that planning methods need to better reflect the flexible and organic nature of work and teams in today’s company. Sometimes work involves 400 people on 1 project, but more likely, work involves 4 people on 100 projects, with those 4 person teams shifting dynamically based on the specific problems at hand.
Let us know what you think. We want Goshido to help empower you to work more effectively.
New Years Resolutions? It’s not too late!
Posted on 03. Feb, 2011 by tom in New Ways to Work
Punxsutawney Phil has made his annual appearance, but given the mountain of snow in my front yard, I hope you’ll forgive my skepticism regarding his prediction of an early Spring. By this time of year, many of us are happier to see our old classmate Ned Ryerson than think about the New Years resolutions we’ve already left behind. Fortunately, it’s never too late to learn about new ways to work.
Goshido is all about helping individuals, teams and organizations work more effectively. No matter where you sit in an organization – Enterprise 2.0, social business, or creating a Getting Things Done plan, can help make work better.
I’ve been involved in software-as-a-service (SaaS) businesses since 1999. One of the most gratifying things I’ve seen is the dovetailing of some of the best benefits of SaaS with trends in the workplace, such as Agile. SaaS gives you frequent product updates, tight customer feedback loops, and ad hoc collaboration giving superior service. The benefits of Agile are now extending beyond software development into areas such as sales and marketing.
The new ways of work are here to stay, and Goshido is designed to help you make the most of them. Take a look and let us know how we’re doing.
You can try Goshido at no cost today.