Home » Posts tagged 'adoption'
Tag Archives: adoption
LeanKanban United Kingdom 2013 Video up
Hello everyone,
Just wanted to point out that the Lean Kanban United Kingdom videos are all up! Check out my talk on Myths and Misconceptions about the Kanban Method in addition to all the other great talks from this conference.
http://www.youtube.com/watch?v=-9vLfEz4aqY&list=PLVsUnwOzPqiRZ2cnrzfKFnDEDTqL3pr5-&index=28
You can find a lot more information on the LeanKanban Conference series here.
I hope you all have Happy Holidays and a Prosperous 2014!!
Cheers,
Dave
The Kanban Method – Change Catalyst with No Changes Planned
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.
Final Thoughts
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.
Intro to Kanban at the Calgary .NET User Group’s Lunch Series
I recently had the privilege to speak that the Calgary .NET User Group’s new lunchtime series. This series is an opportunity for people to come and hear about exciting new topics with a minimal time commitment. And in this case, CNUG President Dave Paquette felt is was about time that we have a talk about Kanban.
Here is a link to the video of my 50+ minute presentation. It’s the first time they’ve video taped one of these, so please don’t be to critical of the quality. 😀
You can find the slides on Slideshare here.
The one thing I’d like to pull out specifically from this presentation was the exercise we went through (11:24 in the video) in understanding what it was we were actually talking about. In my slide deck, I indicated there are three common definitions of kanban out there and that we really needed to understand which one we were talking about in any conversation around the topic. And in an informal little survey of what participants though kanban was, we got the all three definitions from different people in the audience. The three commonly confused definitions are:
- kanban – signboard, visual signal, card
- kanban system – pull-based work(flow) management system, normally at the heart of a kanban method implementation
- Kanban method – An approach to incremental, evolutionary process change for organizations
Very often when I am discussing the Kanban Method with people who are new to any of these ideas, they are often getting them confused and it is really important that we clarify which we are talking about.
Do you know what Kanban you’re talking about? 😀
ALM Adoption Success Story – Success Factor 2 – Visualize Your Work
Humans love pictures.
We have numerous sayings in our cultures about how powerful visualizations are.
“A picture is worth a thousand words“
“The drawing shows me at one glance what might be spread over ten pages in a book.”
“Every picture tells a story.”
One that the challenges with knowledge work is that for the most part, most of our work is invisible until it’s done. Only Neo can see bits and bytes which leaves the rest of us a little in the dark. If you’re building a building, or digging a hole in the ground, progress is obvious! For invisible work, progress is very difficult to monitor.
So we track work in some software system, but then we hide all of our knowledge in text and numbers! Our love of spreadsheets is epic in proportion. Status reports! MS Project files! All of this data!! For all intents and purposes, our work is still invisible! We often mistake this data for knowledge and understanding and the true insights are left hidden in the numbers.
On our project, we knew it would be very important to understand at a glance where we were in our workflow. We were doing something very novel for this organization and in order to mitigate the risk of heading too far in the wrong direction (which could be any direction at this point), we needed knowledge. We needed to quickly identify roadblocks to progress, which often included self-inflicted delays. We needed to engage with our sponsor in a meaningful manner.
So we started drawing pictures!
The most important “picture” that we have used has been our storyboard. This board is very important to us. It is a muster point for our daily stand-up meetings. It is a place on which to hang “adornments” that help us quickly assess our current state. It is a tool that promotes conversations. And it is always there, silently reminding us to be disciplined with efforts to visualize our work.
Our storyboard looks like pretty much like any other Agile teams storyboard in form, but this one is a unique work of art. Well, unique in that it is exactly what we need it to be at the moment. It represents our workflow. We have our WIP limits on it. And because we are fairly disciplined in maintaining the current state of all our work, it’s always up to date.
We also visualize our tasks and review these daily as well. TeamPulse has a story board as well as a task board for more granular visualizations.
We don’t have WIP limits enabled on the tasks boards, but again, the intent is to see work flowing through the system. And with an explicit policy that tasks should have a cycle time of 1 day, any time an item is discussed at 2 stand-up meetings, the team knows that the work isn’t progressing as expected and some sort of investigation and corrective action may need to take place.
Finally, we use TeamPulse dashboards to visualize our progress over the course of an iteration.
Everyday, we review the storyboards and the tasks boards during our stand-up, and then we review the dashboards to bring the entire conversation back to our progress versus our (the team’s) expectations for the iteration. These dashboards provide that high-level perspective that ties everything back together.
And all of this information is available on the web, to everyone on the project team, including the sponsor. There is no need to interpret numbers. There isn’t a report that needs to be compiled. And the information we want to present is immediately available in a very easy to consume and impactful format because a picture is worth a thousand words!
Going back to the first ALM Adoption Success Factor of Transparency, having something to be transparent with has been a key enabler of success for our team as we strive to deliver this project and continuously improve and get better as we do it.
Series List
- Success Factor 1 – Transparency
- Success Factor 2 – Visualize Your Work
- Coming soon – Success Factor 3 – Co-location
- Coming soon – Success Factor 4 – Invest In Your Tools
- Coming soon – Success Factor 5 – Retrospectives
ALM Adoption Success Story – Success Factor 1 – Transparency
This is a story about my job, which I love.
During the day, I’m a mild-mannered process consultant (read: Lean/Agile evangelist) for Imaginet, a technology consulting firm that provides end-to-end software development services primarily specializing in Microsoft products and technologies. The really cool thing about Imaginet is that we are large enough to be able to help companies with projects that span the full lifecycle of solutions development, or Application Lifecycle Management as it is more well known. And these projects often involve helping organizations adopt, refine or improve their existing ALM processes.
That is the part that I get excited about. As a process consultant and change agent, I get to help companies take their development processes to the next level and build an organizational culture that is capable of continuing that growth.
It was in this context that our current client engaged us. They were going to build a team that was expected to build a mobile transportation solution that would help them manage a fleet of trucks. This client had never had a core competency in software development but realized that in order to realize their vision, they would need to become competent as there was no off-the-shelf solution that would fit their needs. They did have experience with traditionally managed knowledge work projects and really felt that this was not going to lead to a successful project. There were far too many unknowns and risks and they knew they would need to learn and adapt very quickly throughout the project.
So we all decided to adopt an Agile/Lean mindset and build a process that would help us deliver in this challenging situation.
This long preamble is really just setting the stage for me to share with you what I think were the 5 core principles that we used on this project to ensure that the mindset and methodology development worked and became institutionalized. I’m hoping that by showing you how they affected the way that we work and the benefits, you’ll be able to learn from us and see if they could work for you. This 5-part series won’t be as much about the methodology we ended up with as much as it is about how we ensured that the right methodology for the organization and project emerged and that we maximized our chances of success.
Success Factor 1 – Transparency
The first core principle that we followed was to provide as much transparency into everything that we did, the information that we had and the challenges that we faced. We were so focused on this transparency that it actually tended to border on continuous broadcasting.
In an environment where there is a lot of uncertainty and risk, we felt that it was crucial to our success that we get as much information as possible from as many sources as possible and to engage anyone who could help us succeed. And with a project sponsor who was taking a significant risk in building a new competency for his organization, it was important that he see how we were working, the challenges we faced, and that we were always looking to improve the way that we worked.
To that end, we used numerous tactics to provide as much information on how we were working at a glance to anyone who was interested. These tactics included:
- a big team room which encouraged information sharing and broadcasting
- digital storyboard (work management system) that was projected onto a screen at all times and accessible anytime from a browser
- daily stand-up meetings where anyone was invited to attend
- iteration planning and retrospective meetings every 2 weeks, anyone could attend and the outcomes of these meetings were left in plain sight for anyone to see
- team Skype account that would auto-answer (silently I might add) and project onto the screen, with a live video feed and multiple microphones in the room
- Skype accounts and webcams for all team members
- tons of whiteboards and large post-it notes that we write on continuously – every wall in the room (600+ sq. ft room) was covered in information and updated frequently
- large post-it notes on the wall outside the team room to notify anyone walking past in the hall
- email notification of significant events in the development process (e.g. broken builds, server outages)
And it is working!
Our sponsor, who sits across the hall, frequently comes into the room and sees exactly what the team is doing. Our openness has fostered a culture of trust between him and the team that allows both to ask questions, provide inputs, and make decisions for the good of the project together. And one of the really cool aspects of his interactions with us is that he very rarely comes in and asks us how we are doing or where the project is at. He already knows! He usually comes in asking about a specific item we are working on, or asking if he can help with one of our problems.
We never have to defend our methodology because we are constantly sharing it with everyone and allowing them to participate in its improvement. This is one of the hard parts of an Agile adoption project that is easily avoided by aggressively being transparent.
Another benefit of this level of openness is that when we have brought on a new team member, which has happened several times, they are immediately immersed in a LOT of project information. This ranges from work in progress, upcoming stories, improvement work items from the retrospective and any risks or challenges that we are actively facing. We also have numerous big PostIt notes that contain the values and principles that we have chosen to follow as we evolve our methodology. How we perceive value, prioritize and the core vision for the product is all up on the walls all the time.
We have received help from a variety of people within the organization who saw something that we had on our boards that they could help with. These helpful acts ranged from sharing critical bits of information that helped us make a much better decision to actually removing a roadblock or impediment from our current blockages. And without this level of transparency, there is a good chance that these helpful acts would have been delayed if they had even arrived at all.
Transparency has been, and will continue to be, a significant cultural aspect of our team that we feel helps drive our success.
Do you have any transparency tactics you’d like to share? Please do! Comments and thoughts are always encouraged!
Cheers.
Dave
p.s. I plan to enhance this post with pictures soon, but I’m under a deadline to get this out (thanks Dylan) so they’ll have to wait! Please check back in the next couple days.
p.p.s. This blog is being inspired by a competition between a bunch of us to see who fails the blogging frequency requirement first! Please check out the blogs of all these other awesome guys and encourage them to keep on blogging too!
Series List
- Success Factor 1 – Transparency
- Success Factor 2 – Visualize Your Work
- Coming soon – Success Factor 3 – Co-location
- Coming soon – Success Factor 4 – Invest In Your Tools
- Coming soon – Success Factor 5 – Retrospectives
Agile Ramblings 