When slicing the Agile 2009 conference and looking at trends, there was a lot of talk about Kanban, Mainstream Agile and using Games for improving and learning Agile/Lean techniques. But also group dynamics, how we are working together, how we collaborate and how to create a shared vision were included in many sessions and discussions.
Games
There were many games at the conference, and it was very interesting to see how people got involved in another way when playing a game using Agile and Lean techniques, instead of trying to understand someone explaining some principles and practices. Using games in teaching will make it much more effective and fun. I will start to include more games in the future, when facilitating workshops.
Kanban
There was also a lot of "Buzz" about Kanban, and I can see a lot of interest in my Kanban talk on September 15th. A Kanban system can be used to implement different Lean techniques in your Agile processes. It can be a more visible way to look at flow in the daily work, limit the work in progress, establishing a cadence etc.
I got a lot of interesting input to use on my Kanban talk on September 15th and also to include a Kanban game instead of different exercises on the Kanban workshop on October 28th.
Experience reports
Experience reports were also a main topic, and it is very important to capture and share the learning from real life problems, failures and success.
You can get the experience report I wrote for the conference from http://tinyurl.com/CmmiAgile and the slides from the Agile 2009 session on http://tinyurl.com/nk2g5p. It is about Agile with distributed team, scaling Agile teams, creating a kaizen culture across many teams and continues to deliver more business value.
Collaboration tools
Looking back at the conference, I also see a trend for more collaborative Agile tools. Many people talked about tools to support better collaboration and communication. I have a number of business cards from different venders, who created a new Agile tool with more collaboration and asked me to have a look at the free version. It will be interesting to see how those tools will evolve in the future.
I also talked with some people from EMC | Conchango and played with their integration between TFS and a smart board. See picture below. Using the smart board, you collaborate with stories from TFS, do estimation with planning poker cards and have the values saved directly back into TFS. A fun and costly solution.
EMC| Conchango software integration a Smartboard into TFS
A cheaper solution is the Wii virtual whiteboard from Johnny Chung Lee. http://johnnylee.net/projects/wii/. It can be a easy way to make a virtual task board, see also this YouTube video.
I went to a few sessions at the Agile 2009 conference related to group dynamics, hyper productive teams and corporate culture.
Help me to see... corporate culture with Tobias Mayer and Lyssa Adkins. "Using a simple yet effective collaboration game from the Improv tradition this session will challenge our assumptions and open up new neural pathways." It was a very interesting workshop with a limited number of people. Tobias showed us different techniques to describe a new reality for an agile person, an agile team and an agile organization in a collaborative and simple way without being locked in our traditional beliefs.
Help me to see...
Scaling Up by Scaling Down: A (re)Focus on Individual Skills with Ashley Johnson and Amr Elssamadisy. The key message on this session was to focus more on developing personal agility, before trying to scaling up. The primary aspect of agile is skills and personalities (Individuals and interactions over processes and tools…).
Scaling Up by Scaling Down
Some of the quotes from sessions and discussions:
- "The pain of change has to be less than the pain of failing"
- "Trust and credibility is the glue, if you don't create it you will fail"
- "Before getting it to work in the large, we need to get it to work in the small"
I think from an agile point of view, we need to understand our craft much better and focus on business value, innovation and continuous learning.
We talk more about "How we create the solution" than "Why do we create the solution?"
We talk more about "How great we are doing" than "How we can continuously improve and be better?"
We talk more about "How can we be more productive" than "How can we create less useless features?"
I think we should focus more on
- Building a better understanding on what we are doing – create a unity of purpose
- Working with continuously improving and learning in the organization
- Teaching and using problem solving techniques
- Structure our work with cadence, flow and pull
- Establishing more transparency and accountability
What do you think?
In this slice about inspiration from Agile 2009, I will write about the inspiring elements from different sessions and discussions with other participants. It will be more facts than thoughts and trends (I will cover that in later blog posts, slicing the Agile 2009 conference).
For me, the primary source of inspiration was from the workshops involving some kind of games. Games can be a great way to learn about different practices, principles and tools. Especially because they don't have elements from your daily work, so the collaboration between the participants often will be much better and focus on the complete team, a shared goal and not specific roles (well, well, I know we have all those agile cross functional teams…but…).
I went to The Business Value Game with Portia Tung and Pascal Van Cauwenberghe. It was a game about how to deliver maximum business value, prioritization, estimate business value and collaboration between different roles. The session was a bit chaotic with too many people in the room, but it got some really interesting concepts. It was also interesting to see how people got engaged in the game. I observed many people focusing quite a lot on learning the game rules and less on optimizing the business value. For example in my team, we did not talk about remove stories from the game to release more frequent, but tried to maximize the delivery of ALL stories. Maybe it was because the session had too many people and we did not have the time to think on that strategy, but it might also be a pattern in many real teams?
The Business Value Game
Portia and Pascal also facilitated the The Bottleneck Game, and some of my colleges from BestBrains went to that workshop. It was a game about options, Theory of Constraints, System Thinking and collaboration on a common goal. It is a great way to learn those agile and lean techniques. I will defiantly use this game with different teams.
I also went to The Kanban Game with Tsutomu Yasui. It was also a workshop with too many people and it took some time before we had enough problems to manage in the iterations of the game. After the first iteration it got more interesting and had some good elements. I think the game could be much better, by not having the first iteration and maybe facilitate the usage of different Kanban elements.
The Kanban Game
Another fun and inspiring workshop was May the Forces Be With You, Exploring the Forces Driving and Restraining Agile with Rod Claar and Douglas Shimp. We created two teams, the Drivers and the Restrainers and had to present different forces in a humoristic way for some selected judges. It was a fun way to explore the forces driving and restraining agile
May the Forces Be With You
"Flirting" With Your Customers with Jenni Dow and Ole Jepsen was a fresh way of looking at the customer relationship using 8 steps to build a good customer relationship. It was fun and interesting.
Flirting With Your Customers
The last session I will include in this slice, was a workshop, First, kill all the Metrics!, with Niel Nickolaisen and Chris Matts. We talked about many potential meaningful metrics, but did not find some really good examples in my group. I might reflect more on this area in a later Agile 2009 slice.
First kill all the Metrics!
Talking with other participants were also fund and inspiring, but I did not had the time to talk with enough people. It was inspiring to hear agile and lean stories from the trenches around the world, even though many people and teams seem to struggle with retrospectives and problem solving techniques.
In this slice about the Agile 2009 venue, I will write about the city, the hotel and include some elements from the two keynotes.
I liked to be in Chicago, it is a pleasant city with a breathtaking skyline. People asked me a couple of times, if I needed any help when I tried to figure out where I was on my city map. It looked like the residents were quite relaxed and helpful. Not like in some other US cities I have visited. The hotel was ok, but not special. Most of the conference rooms were located in the basement, so I used many of the breaks to get up and out of the building to breath fresh air.
Back in time, there has been a lot of innovation in Chicago and the city plans and architecture are quite unique. In 1871 there was the big fire in Chicago, where 17,500 buildings were destroyed, many people got homeless and a large part of the city had to be rebuilt. Chicago also had another very special problem: It stood on swamp. Actually they changed the catastrophe into an opportunity and found an innovative solution to the swamp problem by constructing the world's first completely iron-and-steel-framed building. The skyscraper.
It is interesting to think about the reason behind inventing and constructing the skyscraper. They had a huge problem, and found an elegant solution to solve it. That's innovation! Maybe we could learn something about innovation by looking back at the invention of the first skyscraper?
In the second keynote at the Agile 2009 conference, Jared M. Spool talked about what it takes to build a design team that meets today's needs. Jared talked about how to integrate the needs from the users in the design process and not "just" build more software. "Unfortunately" he had several examples of companies using billions of $ on designs that did not deliver more business value. I think we often in the software community are more focused on delivering more software in a high effective way, than actually inventing the innovative solutions. The solution with the skyscraper was great, because it was a solution to a huge need after the big fire and the problem with the city on swamp. It was tomorrow's solution for today's problem.
We might find much more value by looking at why we build software rather than building more software faster and faster!
In the first keynote, Alistair Cockburn talked about agile being more main stream, the iceberg is melted down in the ocean. He also talked about how important it still was to have trust and effective communication. It was very entertaining, but I think there is still a long way to have agile out in the big enterprises.
This year, nearly 1400 attendees contributed to the second largest Agile conference in Chicago, USA. Next year the Agile 2010 conference will be in Nashville.
I have used some time to do some reflection about the conference. I also got back to a more stable internet connection (the internet connection at the conference hotel was not that stable…), so now it is time to do some more thinking and writing.
Instead of writing about all the sessions I attended, I thought it would be more interesting to slice the whole conference in different areas combining the many different viewpoints into some kind of context. If you are interested in all the sessions, you can find the complete program with all the sessions at www.agile2009.com.
I have selected to view the conference from the following 5 slices:
For the following days, I will post a new slice. In that way, I will try to incrementally create a more complete view of the conference and try to put the value from the sessions into a context. At least from my point of viewJ.
Stay tuned more to come.
One of the very efficient tools I have used for many years to do visible, focused and shared planning is to create a task board on a whiteboard. When working in an iterative process, like Scrum, it is a good way for the team together to plan the iteration, create tasks and share knowledge.
In this post I have different examples of task boards and Kanban boards.
Figure 1: Task board extended with a visible state for Review
Figure 2: Example of Task board (see the max limits on QA)
Figure 3: Another Task board with more review states
Figure 4: Web based Task board for a global team with integration to Microsoft Team System
Describing the process on a whiteboard and moving into a Kanban board.
Figure 5: The process on the initial kanban board
Figure 6: Kanban board implemented, already with improvements
How do you more efficiently improve your software development?
There are many different silver bullet methodologies about the "right" way to make software development (XP, Scrum, Crystal Clear, DSDM, Prince2, RUP, MSF, CMMI, IPMA, Lean etc.), often categorized as either waterfall, or agile.
But basically it is not about using the hottest, newest or most used methodology or framework. It is about making more efficient software development.
Don't go for the silver bullet framework, but build your own recipe and look at some of the different candidates to do more efficient software development. . Based on my experience, I see a pattern to look at:1) Development craftsmanship, 2) Processes and 3) Requirements Management. Also the A) Management System and the B) Culture in the company is important to focus on, if you want to have more efficient (continuously improving) software development. Of course there is an interrelation between the different areas, which is not that easy to work with.
I have tried to visualize it in the following diagram:
- Processes - "How do we work together?"
In a team, between specialists, department, with the rest of the organization and with external partners and customers. How do we make sure that we work on the most important tasks at the right time? What makes most business value?
- Craftsmanship - "How do we make the software?"
Good development practices supported by an efficient development infrastructure to establish different feedback loops with builds and automated testing. Using patterns, emergent design, TDD, CI, Refactoring, done-done etc.
- Requirements - "What business needs do we solve?"
Managing of business requirements and to make sure the solution is created to solve the right business needs. Including planning, goals, business value, acceptance criteria etc. What is enough? When is it done?
A. The Lean-Agile Management System
Between and around the three areas, there is the Management System in the organization and with a Lean-Agile mindset, it support and improve the flow of value and establish more focus and rhythm for all people. Establishing focus on the key value streams and moving more responsibility to the people performing the actually work makes much more productivity and improved quality. It is hard, a mindset change of old management practices, but it is so great to see more engaged people working on creating more optimal business value.
B. The Culture in the Organization
What is the culture? It is the combination of many things and hard to define. It is for example how we trust each other, collaborate, and use feedback on tasks and behaviors. Why are people motivated (or not)? Is it just a job or a passion, do we make a difference on our job? Do we respect each other? Are we pushing or pulling work between each other? Do we let people be innovative in their work?
When changing to new ways of performing our work, this strange thing called culture has an impact on the change. Can the culture be changed? I think it can, but it often takes a lot of time, because people like to do what they are used to do.
I will write much more on this topic in the future, because there are so much more for me to say :-).
It is all about trust, respect, collaboration, feedback and understanding the small (or big…) difference between different cultures.
I had a very interesting experience years back when I started working together with people from the other side of the world. Initially we had started a larger CMMI multi site project to establish a common process foundation between the two organizations. We started the CMMI journey based on a lot of advice from people (experts?) working with offshore development, so called "best practice". After the initial startup, it was oblivious that we had to move away from the heavy specifications and focus more on collaboration, frequent feedback and start building more trust between the teams.
I introduced Scrum as the project framework and did some training of both the local and offshore teams on the process, how to work with user-stories, poker estimation, tasks boards etc. It was more a top-down approach, everyone jumping in the water at the same time. In the beginning it was a bit chaotic and many things had to be managed, discussed and changed in the beginning. After some time we established a rhythm and it worked better and better. The teams in both locations started to improve more and more doing retrospectives and trying many different new ways of working. More automation was stated with improved quality and focus on the development craftsmanship.
Some of the elements that worked well and improved the distributed work, was
- Proxy PO role on the offshore location for the offshore team to get faster feedback.
- Two weeks Sprints with a "Sneak preview" from the offshore team to the onshore PO.
- Daily Scrum of Scrum meetings with Scrum masters from local and offshore teams surfacing problems to me on a daily basis (very efficient and important).
- Global Retrospectives with teams from both destinations.
- Heavy use of Skype, webcams, Go-To meeting.
- Focus on automated builds and CI with unit tests.
- Establishing development standards for all teams.
- Working on same infrastructure (Team System – started on TFS2005, beta3 :-).
- People from both locations traveling to the other location and working together with the other teams.
- Focus on domain transfer to the offshore team with PO visits to the offshore location.
- Definition on "done-done", acceptance criteria, improved User Story concept.
A good development infrastructure is always one the important areas to establish and in a setup with distributed teams maybe working in different time zones it is even more important.
Establishing distributed software development must be a long term strategy, because it takes time to build the system with shared processes, rhythm, thrust and with focus on continuous improvement.
I was some years ago told an interesting story about difference in culture when working with Chinese people:
In Chinese there are more than 20 ways of saying "No" and more than five of them actually include the word for "Yes". So as a foreigner, you might hear a "Yes", but basically the reply might be: "No".
So look for the small details and understand the other culture, use more collaboration and establish a more frequent feedback rhythm. Use the different ways of visualizing what you are talking about so you have a common understanding and the same problem.
In July, I went to a Scrum Product Owner course by Roman Pichler in London and am now Certified Scrum Product Owner. Basically I have worked as a Scrum Product owner for several years with different products, but it was inspiring to hear Romans presentation on PO different techniques. Especially techniques related to the product vision, the Product Backlog and Release Management was interesting and highly valuable for my daily work. Roman also used some time on the basic Scrum framework and the different roles, but it was just the basic stuff.
One of the interesting discussions and a great "take away" was Romans insights on the upstream processes in an organization and the impact on a Scrum process. There is a long history for having big waterfall processes to manage Strategy-, Portfolio- and Product Management and when the waterfall reaches the Scrum process it is with a big PUSH. Scrum is based on Pull processes and in between the Product Owner might be caught in a hard situation. If the Product Owner cannot keep the waterfall back, there is a big risk that it will wash away Scrum and take away the empowerment of the Scrum team.
So you also need to change the upstream processes and here the Product Owner plays a central role to make that change happen in a sustainable way.
On Tuesday June 24th, I attended a session with Mary Poppendieck at the IT University of Denmark. Mary did a talk with the title "Is Agile a Fad?" with the subtitle "Will Agile Software Development end on the Dumping Grounds of History?". Bestbrains had invited to the session with Mary.
Mary talked about different Fads in history and boxed the past in decades, starting from 1960 with Ad-hoc processes going to more structure in the 1970 up to the Agile movement in 2000.
I thing one of the interesting points Mary talked about, was the big changes in processes looking back in the history. She visualized it with a pendulum going from ad-hoc to very structured and back again. It is a rather binary approach with no stop in the middle.
Why don't we learn from the knowledge archived in the past and find a balanced state in the middle not having either A or B but the best from both sides according to the current needs?
I strongly agree with Mary and I think it is an important point to realize that you should not just look at a new process as the silver bullet to solve all your problems. You have to build your own recipe according to your own needs and context. It is more important to establish a structure with focus on continuous improvement than to implement a specific process like Scrum, XP, RUP, CMMI etc.
Bent Jensen from Bestbrains introducing Mary Poppendieck
Many organizations are introducing Agile practices like Scrum, XP etc. to get some more value in software development. An important area that is not covered so much with Agile practices is the more holistic view of the whole system. In many situations Agile practices are focused against the development team as the primary area and not covering the end-to-end processes involving the total value stream from problem to solution.
A combination I have seen working well is to combine practices from both Agile and Lean Software to get both the team and end-to-end processes handled in a sustainable way.
Don't only look at the team by introducing Scrum or another (silver bullet) process. You need to start changing the total system in the organization involving all people.
It is Business-IT alignment and one of the key roles is the Product Owner / Product Manager / Product Champignon etc., because this is one of the good candidates of a bottleneck for the rhythm in the total value stream.