Prathima's Miles & Milestones

Fangirl of Kent Beck and Don Wells’ practices

• Computer science is a young science. Building software is more like creating a work of art, it requires creativity in design and ample craftsmanship to complete.
• Agile processes accept the reality of change versus the hunt for complete, rigid specifications. Agile also means a fundamental change in how we manage our projects. Instead of managing our activities and waiting till the project ends for software, we will manage our requirements and demonstrate each new version to the customer.
• XP is Software Development Methodology created by Kent Beck, March 6, 1996. The methodology takes its name from the idea that the beneficial elements of traditional software engineering practices are taken to extreme levels.
• XP is a lot like a jigsaw puzzle. There are many small pieces. Individually the pieces make no sense, but when combined together a complete picture can be seen.
• XP improves software quality and responsiveness to changing customer requirements. It facilitates frequent releases in short development cycles.
• XP improves productivity and introduces checkpoints at which new customer requirements can be adopted.

1. Most Important Features First

• Respect your customer by acknowledging their expertise, listen carefully, defer to their authority, and never insert your own opinions into your code. You can’t learn in weeks what someone else learned over years.
• Important means different things to different teams. You can choose the highest return on investment (ROI). You can choose the architecturally significant features first. A risk is a very important way to sort. You can choose the features in groups that make good business sense together. Most projects settle on a combination. The one constraint is that the customers guided by estimates of effort from developers choose what is most important next.
• Estimates or Stories are the currency of your project. Like money, they don’t have much value themselves, just a piece of paper, but they represent value and can be used to buy things. Stories represent valuable software to customers, time to developers, and negotiable increments of scope to managers. Stories without value to the customer are counterfeit. Destroy any stories that have no value.
• Important project decisions are difficult and stressful. Agile projects distribute the responsibility for decisions amongst the entire team. Developers make technical decisions, managers make people decision, and customers make business decisions. If one person makes all three decisions, then its a lost battle for sure.
• Spending a million dollars on a software project does not mean you have software worth a million dollars. If your customers think being part of software development is wasteful you might be building the wrong software. Don’t just sort user stories by importance, sort your entire portfolio of potential projects by importance as well.
• Once we know what we want to build next we will use iterative planning to stay on track.

___________________________________________________________________

2. Iterative Planning NOT Iterative Development

• You must adapt as the project unfolds by changing your plans. You change plans based on feedback from incremental delivery of working software. Shorter iterations give more opportunities to plan.
• There are three Agile levels of planning.

Release planning is a group of stories selected because they represent a usable set of features that can be released together. These types of plans are made by selecting the stories and deciding how many iterations are needed or by selecting a release date and seeing how much can be done by then. Release plans have no details other than a list of stories to be done by a date.

The second level of planning is the iteration or sprint plan. This plan is a subset of the release plan stories that will be done in the very next iteration or sprint. Only one iteration plan exists at a time. With our chosen collection of important features, we can now estimate the amount of effort to implement them. The people who will do the work, namely the developers, have the authority to set the estimates. The manager will set the total amount of work that the next iteration can have planned. The customer then chooses a subset of the most important features that will fit into the next iteration. The iteration plan will often be verified by breaking the stories into development tasks and estimating them with finer grain units. At this level use cases could also be created. This greater level of detail is permissible because iterations or sprints are kept very short.

The third level is the daily plan. A daily plan isn’t usually represented by any artifacts. At the daily scrum or stand up meeting everyone will announce their plan for the day and then act on it. Even greater detail is allowed because the plan’s duration is one day and no more.

• The goal is to keep a sustainable pace going. When you slip your schedule you acknowledge how far you have come and make a new plan based on the new information. When you get ahead of schedule you make a new plan. Some slack time is nice, but you need to keep your team challenged or they will challenge themselves in ways you wouldn’t have chosen.
• The changes we get late in a project are usually the most valuable because that is when we know the most about our problem domain and solution. Consider every dollar spent on development as also being spent on learning about a better solution. The last change request is always the one you paid the most for, so use it to your advantage.
• Iterative planning is exactly what you think it is; make a plan, build some software, and then make another plan based on what you learned. Agile processes are based on the idea that planning throughout the project is just as important as having a plan. Things change, plans must either be short in duration or very sketchy in details to remain useful.
• How do we know how much we can get done in an iteration or sprint? We need to talk about creating honest plans.

___________________________________________________________________

3. Honest Plans | Estimation

• Agile processes support honest estimates by accepting and mitigating honest mistakes.
• If a mistake is made a new plan is created by accepting how far we have come and revising our plans based on the new information. There is no blame, there is no sense of failure, we have learned something we didn’t know before.
• Velocity will be an important parameter for our iterative planning process.
• The project velocity (or just velocity) is a measure of how much work is getting done on your project. To measure the project velocity you simply add up the estimates of the user stories that were finished during the iteration.

___________________________________________________________________

4. A Project heartbeat

• If your Agile project doesn’t have a heartbeat declare it dead.
• A steady heartbeat has a fixed length iteration as short as you can make it.
• A strong heartbeat produces working software ready for deployment to production with completely finished iteration/sprint commitments.
• A responsive heartbeat creates a new plan each iteration based on feedback from the previous iteration and changing customer needs, not what was left unfinished.
• Shorter iterations actually increase the chances of being done on time not reduce it.
• Work as if every day has a deadline.
• The one essential ingredient that changes repetitive development into iterative development is Feedback.
• A shorter iteration gives you more frequent feedback and more opportunities to learn and steer your project.
• Scrum recommends 30-day sprints while Extreme Programming (XP) recommends one-week iterations.

Goals:

1. You want your team to have a sense of iteration length to work at a steady pace, estimate better, and be fully prepared for iteration end.
2. You want your customer/product owner to see new functionality often so they feel optimistic about progress and can learn about their problem and potential solution quickly.
3. You want managers/scrum masters to feel a sense of urgency in removing obstacles to success so the team continues steadily throughout the iteration and not rush at the end.

• A measurable, predictable, sustainable pace helps you plan and meet your commitments. Developers are known to steal from the future by working many extra hours to stay on schedule today.
• Always deliver working software at the end of each and every iteration. Conduct a demonstration of new features every iteration.
• End every iteration with a retrospective on what could be done better next time. Start every iteration with a planning meeting.
• Iterations must start from scratch and not what was left over from the last iteration. Every iteration should feel like a fresh start, a blank canvas full of new opportunities for an empowered team.

___________________________________________________________________

5. Team Empowerment

• Team is a set of digital Construction workers. Do not bottle neck decisions with a single authority. Change from one person controlling everything to empowering the entire team.
• The most important thing on a project is good leadership; the least important thing is who leads.
• Leadership and management are two very different things. Leadership is about seeing a problem then getting people together to solve it. Any team member who knows enough to foresee a problem also knows enough to lead the solution. It is your responsibility to do so.
• Bad designs can happen to any team if the product vision isn’t strong and well voiced. That is the responsibility of the customer/product owner.
• You will find yourself almost constantly in a leadership role.
• You must be actively involved in most discussions to make sure your vision is followed.
• You will often be put in the unenviable position of breaking hotly debated deadlocked discussions.
• You will decide when the team’s code is ready for deployment.
• The most difficult part will be setting priorities and making the hard decision of what will get done and what won’t. This is a far different role from signing the front page of a requirements specification.
• If your customer is too valuable to spend time with your software team then maybe you are building the wrong software. Ask the customer what would be valuable and exciting enough to make him want to be there with the team.
• Our responsibilities now include deciding how to get organized and what to do next.
• The manager/scrum master will have many new responsibilities. The biggest change is just watching the team interact and being there in the middle of it.
• If relationships are broken then the manager must repair them. If the customer isn’t leading with a consistent product vision the manager must act. An unsuitable customer can lead a team in circles and get nothing done. A developer that breaks the process can slow the entire project down.
• Your team tells you every day at the daily stand up/scrum meeting and you must act to the best of your abilities.
• Eliminate blame as acceptable by making it clear no one wants to hear it.
• You will understand team empowerment enough to mold your process to suit your project and company easily.
• You must eliminate barriers to communication for Agile to work. No one works alone anymore.

___________________________________________________________________

6. Working Software

• Working software is fully integrated, tested, and ready to be shipped to customers or deployed into production.
• It means you created unit tests, QA tests, and actually looked at the output to prove it works.
• We safeguarded all progress by creating extensive documentation of what was decided and what was done (MoM). We had people with authority sign the front page to verify our efforts were going in the right direction.

___________________________________________________________________

7. Daily Communication

• One meeting with the entire team can eliminate much misconception later in the day.
• Developers are responsible for asking the right questions until a clear picture of the problem and a good solution is found interactively.
• Adapting your process to your project in an iterative way. On a regular and frequent basis, you will talk about your project and corporate culture to figure out how the process needs to change. These meetings are called retrospectives and are a very important part of the iterative process.
• Schedule a retrospective after each iteration or at least every other iteration. Ask team members what needs to be improved and what worked well. Also ask what is extra process baggage that can be eliminated.

___________________________________________________________________