Deliver Something of Value Every Week

Deliver Something of Value Every Week

• You break big problems down into smaller ones. You have to break big, scaryproblems down into smaller, simpler, more manageable ones.

• You focus on the really important stuff and forget everything else. By delivering something of value every week, you are forced to get lean and drop anything that doesn’t add value

• You make sure that what you are delivering works. That means testing—lots of it, early and often.

• You go looking for feedback. Stop and ask your customer

• You change course when necessary. Things change. What was really important

one week can be descoped the next.

• Yo u become accountable. When you commit to delivering something of value every week and showing your customer how you’ve spent their money, you become accountable.

How Does Agile Planning Wor k

• Planning an agile project. Instead of to-do lists and tasks, the master story list is your project to-do list contains all the high-level features (user stories) your customer will want to see in their software. It’s prioritized by your customer, it’s estimated by your development team, and it forms the basis of your project plan.

• The engine for getting stuff done on an agile project is the iteration—a one- to two-week period where you take your customers’ most important stories and transform them into running, tested software.

• Your team members will know how much they can take on by measuring the team velocity (how much you can get done per iteration). and using it as a predictor of how much you’ll get done in the future.

• Being flexible on scope is how you’ll keep your plan balanced and your commitments real. And when reality disagrees with your plan, you’ll change your plan.Adaptive planning is a cornerstone of agile delivery.

Done Means Done

• Delivering a feature in agile means doing everything necessary to produce shippable code. The analysis, design, coding, testing, and usability experience and design. If it can’t potentially be shipped, it’s not done.

How Are Agile Projects Different

• The narrowly defined roles like analyst, programmer, and tester don’t really exist.

• The other thing that’s different about an agile team is that analysis, coding, design, and testing are continuous activities—they never end.

• Quality you’re it, whether you are doing analysis, writing the code,or managing the project.

• Co-location. If there was one thing you could do to dramatically improve the productivity of your team, it would be to have everyone sit together. Questions get answered fast. Problems are fixed on the spot. There is less friction between interactions.

• Engaged Customers. Engaged customers are those who show up to demos, answer questions, give feedback, and provide the guidance and insight necessary for the team to build compelling software. They are core members of the team and full-on partners during delivery.That is also why an engaged customer is necessary for any successful agile project. The next time you get in front of your customer, tell them that two weeks from now you are going to make some problem of theirs go away.Don’t ask for permission. Don’t make a big ceremony out of it. Just take some problem, or some itch that they have, and make it go away. Then do it. Come back two weeks later, show them how you’ve completely solved their problem, and then do it again. Take some other problem, and make it go away.You may need to do this three or four times (maybe more) before they start to pay much attention, but eventually they will.

• Self-Organizing. Self-organization is about checking your ego at the door and working with your team to figure out how you as a team (with all your unique skills, passions, and talents) can best deliver this project. It’s more an acknowledgment that the best way to build teams is to let the role fit the person, instead of making the person fit the role. So, how do you get your team to self organize?

• You let them create the plan, come up with the estimates, and take

ownership of the project.

• You worry less about titles and roles and become more interested

in seeing the continuous production of working, tested software.

• You look for people who can take initiative, like being the masters

of their own destiny, and don’t sit back and wait for orders.

In short, you let the reins go and trust and empower them to get the job done.

• Accountable and Empowered. A good agile team will always want to be held accountable for the results they produce. They know customers are counting on them to come through, and they won’t shirk from the responsibility that comes with having to deliver value from day one. Giving your team the reins to make their own decisions and do what they think is right frees them to take initiative and act on their own accord. They solve their own problems, and they don’t wait for anyone to give them permission.

• The simple act of putting teams in front of real live customers and having them demo their software will go miles toward making your teammore accountable.

Cross-Functional

A cross-functional team is one that can serve their customer from end to end. That means having the necessary skills and expertise on your team to take any feature your customer would need and be able to

deliver it fully.

Without having to wait for permission or negotiate for resources from others, they can start delivering value from day one,with no one in their way to stop them.

Roles We Typically See

Agile methods like Scrum and XP don’t have a lot of formal roles when it comes to projects. There are people who know what needs to be built (customers) and people who can build it (the development team).

The Agile Customer

The agile customer is the “source of the truth” from which all requirements flow on an agile project. Ideally they would be a subject-matter expert. It’s someone intimately familiar with the business, who really cares what the software does, what it looks like, and how it works, and who is committed to guiding the team, answering questions, and giving feedback. They also set the priorities. They decide what gets built and when. why it makes more sense to work on some features before others (in other words, to

reduce technical risk).

But generally they set the priorities from a business point of view, and then they work with the development team to come up with a plan to make it happen.

To do all these things, it helps if the customer is working very closely with the development

...