At Qcon London 2007, Boris Gloger described a 6 step process for performing retrospectives:
1. Security – Do not do a retrospective in a stressful environment. Make sure that no one is to blame. Regardless of what we discover, we understand and believe that everyone did the best job they could given they knew at the time, their skills, abilities and resources and the situation at hand.
2. Collect facts - Have a timeline with post-its about experiences of important events. Have the team members tell a short story of every event that is important from their point of view. Concentrate on facts and not emotions.
3. What went well? – Again, post what went well.
4. What could be improved? – Post what could be improved. Environment, skills, resources, hardware. Gather new ideas.
5. Who is in control? – All the ideas are coming from the team. Who is in control of improving what is discussed. Is it the team or the organization?
6. Prioritize – The goal is to improve the next iteration immediately. Have a team backlog that includes things the team must work on besides the product backlog (training, resources, etc.) Have an impediment backlog that includes organizational issues that impedes the team Prioritize and sort them then and add stories to the next sprint.
The retrospective should take between 10 to 90 minutes. It should not be held in the team room, but instead in a dedicated and neutral room that provides a secure environment. Attendees should include the entire team and whomever else the team would like to include.
This presentation is available on InfoQ at http://www.infoq.com/presentations/Heartbeat-Retrospectives-Boris-Gloger
Saturday, June 28, 2008
Sunday, June 22, 2008
Agile in the Waterfall Enterprise
At Agile 2007, Michelle Sliger
discussed some hurdles that agile teams face in a waterfall enterprise and how to clear them:1. Resistance: There will be resistance from management, the business and the team. Don’t try to sell agile to management. Instead fly under the radar, operate in stealth mode and just go ahead and product working software of high quality. When talking to management about agile, advocate using their language. Avoid using terms like agile, xp, scrum sprints and use terms they are already familiar with like ROI, cutting costs, increasing quality, earlier to market, or share success stories that prove increase in productivity. When dealing with resistance from the business, try to get them involved early on and suggest trying things for 30 days and then have a retrospective. Try to get a client or at least a proxy on site. It is easier to start out with XP technical practices. When facing resistance from the team, try to get the right people on board and empower them.
2. Culture: Review the companies mission statement and see if there are values mismatch between what is stated and what goes on a daily basis. Try to clear up misconceptions of Agile. It’s a new methodology but not a fad.
3. Resource management: What if the organization has a matrix environment. Agile teams are collocated and dedicated to the project. But agile can be distributed, but it won’t be as effective and efficient as collocation. Dedicated is different from devoted. Dedicated means team sticks to the project through completion. Use a release plan or quarterly plan to help resource manager in allocating people. Use release plan and product roadmap to assist project managers in the allocation of the budget.
4. Vendors and Contracting: If a vendor is not agile, evaluate the duration of the relationship. If it is short term, then there is no need to explain agile, but if it is longer, then you should explain it. If customer is not agile, then think about how to present the contract. Start a conversation with them. Would you like us to show you progress on application every 2 weeks? Would you like to change or adjust your requirements after reviewing the progress? Work through time and material contract with option to renew or cancel every 30 days.
5. Facilities and Tooling: Use what works for you. Ask the team and find a solution, create or find an open space, make it a war room, use a whiteboard. Use open source tools.
6. Cost accounting and reporting: How are we going to do the budgeting without a BUFD (Big upfront design document)? You have to do it, but you do it differently. Find out cost per iteration. Find out cost per story points. Find out what metrics need to be tracked. If GANTT chart is still needed then you can give it but duration will always be the same, task assignment will always be ‘TEAM’. Are you capitalizable or an expense?
7. Auditors: talk to auditor and find out what they are looking for. Add those to the product backlog and include them in an iteration to create these docs. Be barely sufficient in your documented proof.
8. Communication is key. Agile is a silver bullet but only if it is implemented properly.. Inspect and adapt and communicate. Have a communication plan in your transition rollout plan. Provide support for sharing knowledge and experience and continued education. Define escalation and issue resolution.
9. Miscellaneous:
- a. passing off code to production (add one iteration to make it production ready – get sign offs, get help desk up to speed, get training materials, get docs).
- b. Reward and recognition: Not about individual performance but about the team making its commitment. How do we do that? Ask the team. As agile team become more and more performing, they will level off. We need to keep them consistently challenged and motivated. Organizational change will happen. Instead of silos, there will be groups around product lines.
1. Find an executive champion that will help you by pulling those hurdles out of the way.
2. Socialize, don’t evangelize
3. Use the power of the backlog It should include more than just coding items.
4. Do not wait until everything is figured out and perfect. Just get started. Later you can inspect and adapt
5. Use barley sufficient guideline. Do the simplest thing possible to satisfy a request
6. Invite non agile reps to all agile planning meeting
7. Establish a rhythm of inspection and adaption
8. Start sending the ideas up the chain. Help your managers become more agile
9. Pay attention to your behaviors and your team’s behavior. It is easy to revert back to the old ways especially under stress and pressure.
10. Include everybody in project retrospective. Improve things in the team and across the organization
Finally, Michelle concludes that Agile and waterfall can coexist. You need to build the bridge together. Invite everyone who is interested to help you with the transition to agile.
This presentation is available on InfoQ at http://www.infoq.com/presentations/Agile-in-the-Waterfall-Enterprise-Michele-Sliger
Saturday, June 14, 2008
Dealing with Organizational Challenges to Agile Adoption
At Qcon 2007, Joseph Pelrine addressed issues dealing with agile adoption.
He started out by describing how an organization is composed of multiple teams with some being flexible and others rigid. The flexible teams have resonance and will quickly sync up with you. Using resonance can help you bring change. However, too much resonance is a bad thing. It’s like how running down hill too fast can make you fall down. The rigid teams Don’t want to change, do not like what you are doing and do not want to move. They will resist your process. You can use this as a buffer so you do not start tripping up. However, too much resistance is not good.
Next Joseph discusses how management is still stuck in Newtonian concepts and mechanics of work where the whole is the sum of the parts. He describes how we deal with different tasks and issues by providing 4 categories based on cause and effect:
1. Simple: Cause and effect is known. Switching a light switch turns light off and on.
2. Complicated: Cause and effect is hidden but knowable. Pressing a button turns a computer on. Pressing button turns on phone.
3. Complex: Cause and effect is retrospective coherence. Cause and effect emerges and system self organizes, but cause and effect is only clear when looking back and in hindsight.
4. Chaos: No patterns of cause and effect. There is no discernable cause and effect.
Between these is a black hole of stuff we haven’t figure out yet. It will stay there until we know which category it belongs too.
Most tasks that management deal with and most deterministic coding tasks are on the side on simple or complicated (know cause and effect). The hard part are thing on the other side like figuring out what customer need and dealing with people. We’ve been taught how to work with 1st set, but are still floundering around with the other set.
Next, Joseph discusses different ways of thinking
1. Process engineering: There is order. Cause and effect is knowable. We can look it up or it or we can call up an expert. This is great for waterfall. When there is order, you can know everything in advance and because agents obey rules you can predict behavior. This is known as process engineering (Taylor).
He started out by describing how an organization is composed of multiple teams with some being flexible and others rigid. The flexible teams have resonance and will quickly sync up with you. Using resonance can help you bring change. However, too much resonance is a bad thing. It’s like how running down hill too fast can make you fall down. The rigid teams Don’t want to change, do not like what you are doing and do not want to move. They will resist your process. You can use this as a buffer so you do not start tripping up. However, too much resistance is not good.
Next Joseph discusses how management is still stuck in Newtonian concepts and mechanics of work where the whole is the sum of the parts. He describes how we deal with different tasks and issues by providing 4 categories based on cause and effect:
1. Simple: Cause and effect is known. Switching a light switch turns light off and on.
2. Complicated: Cause and effect is hidden but knowable. Pressing a button turns a computer on. Pressing button turns on phone.
3. Complex: Cause and effect is retrospective coherence. Cause and effect emerges and system self organizes, but cause and effect is only clear when looking back and in hindsight.
4. Chaos: No patterns of cause and effect. There is no discernable cause and effect.
Between these is a black hole of stuff we haven’t figure out yet. It will stay there until we know which category it belongs too.
Most tasks that management deal with and most deterministic coding tasks are on the side on simple or complicated (know cause and effect). The hard part are thing on the other side like figuring out what customer need and dealing with people. We’ve been taught how to work with 1st set, but are still floundering around with the other set.
Next, Joseph discusses different ways of thinking
1. Process engineering: There is order. Cause and effect is knowable. We can look it up or it or we can call up an expert. This is great for waterfall. When there is order, you can know everything in advance and because agents obey rules you can predict behavior. This is known as process engineering (Taylor).
Thursday, June 12, 2008
Agile Architecture is not Fragile Architecture
James Coplien and Kevlin Henney gave a talk at QCON London 2007 addressing the myth that architecture can’t be agile. It is heavy weight and the magic of Agile makes it unnecessary to bother with up front design.
They define a good architecture as something you can do upfront that is light weight that helps you understand the significance of the decisions that you are going to make. It allows you to look at the system make judgments about what things you can differ and what things you should not differ. To be agile you must be fit. You must be standing on a firm foundation. Agile is about understanding what changes we can ignore. You cannot defer all important decisions. Later you will have a lot in place that you can’t do anything about it. A lot of things have to be pushed upfront. Understand the repercussions of a given decision. See the big picture, make a shared vision across the team and use it as a tentative foundation. Describe the things that really matter. Make the critical design decisions. Architecture is not something that lives in a document. It is not a blueprint. The design document is in the code. Architecture is a shared vision that builds on the knowledge of your people. It is about understanding the thing we need to build and how we will build it. It provides a foundation for team structure, a foundation for the GUI and reflects the system architecture.
According to the Oxford dictionary, the some definitions of agile include quick motion, nimble, active, or ready.
They discuss prioritizing and mention that you do not want everything to become significant. We need to know what to care about to reduce the significance of other decisions. Making hard decisions early makes easy decisions easier. Doing the easy ones 1st constrains you and makes the hard ones even harder.
Then they address big upfront design (BUFD), no upfront design (NUFD), and rough upfront design (RUFD) and suggest that there is tension between the levels of detail and a balance is required. The right amount of design depends on the size of the domain and the recommend 1 or 2 weeks. If using Scrum, then have a single Sprint that delivers the architecture as abstract classes.
They wrap up by illustrating what happens if you start immediately without any design and how if you don’t pay now you will end up paying a lot later. They stress on trying to figure out what is critical and what is not critical and spending time on the critical upfront.
This presentation is available on InfoQ at http://www.infoq.com/presentations/Agile-Architecture-Is-Not-Fragile-Architecture-James-Coplien-Kevlin-Henney
They define a good architecture as something you can do upfront that is light weight that helps you understand the significance of the decisions that you are going to make. It allows you to look at the system make judgments about what things you can differ and what things you should not differ. To be agile you must be fit. You must be standing on a firm foundation. Agile is about understanding what changes we can ignore. You cannot defer all important decisions. Later you will have a lot in place that you can’t do anything about it. A lot of things have to be pushed upfront. Understand the repercussions of a given decision. See the big picture, make a shared vision across the team and use it as a tentative foundation. Describe the things that really matter. Make the critical design decisions. Architecture is not something that lives in a document. It is not a blueprint. The design document is in the code. Architecture is a shared vision that builds on the knowledge of your people. It is about understanding the thing we need to build and how we will build it. It provides a foundation for team structure, a foundation for the GUI and reflects the system architecture.
According to the Oxford dictionary, the some definitions of agile include quick motion, nimble, active, or ready.
They discuss prioritizing and mention that you do not want everything to become significant. We need to know what to care about to reduce the significance of other decisions. Making hard decisions early makes easy decisions easier. Doing the easy ones 1st constrains you and makes the hard ones even harder.
Then they address big upfront design (BUFD), no upfront design (NUFD), and rough upfront design (RUFD) and suggest that there is tension between the levels of detail and a balance is required. The right amount of design depends on the size of the domain and the recommend 1 or 2 weeks. If using Scrum, then have a single Sprint that delivers the architecture as abstract classes.
They wrap up by illustrating what happens if you start immediately without any design and how if you don’t pay now you will end up paying a lot later. They stress on trying to figure out what is critical and what is not critical and spending time on the critical upfront.
This presentation is available on InfoQ at http://www.infoq.com/presentations/Agile-Architecture-Is-Not-Fragile-Architecture-James-Coplien-Kevlin-Henney
Subscribe to:
Posts (Atom)