scrum.boulevart.be

1. The team is empowered to make decisions.
2. The team is self-organising and does not rely on management to set and meet its goals.
3. The team commits and takes responsibility for delivery and is prepared to help with any task that helps the team to achieve its goal.
4. The team knows who the product owner is.
5. Each sprint/iteration has a clear goal.
6. All team members, including testers, are included in requirements workshops.
7. Requirements documentation is barely sufficient and the team collaborates to clarify details as features are ready for development.
8. Test cases are written up-front with the requirements/user story.
9. There is a product backlog/feature list prioritised by business value.
10. The product backlog has estimates created by the team.
11. The team knows what their velocity is.
12. Velocity is used to gauge how many user stories should be included in each sprint/iteration.
13. Sprints/iterations are timeboxed to four weeks or less.
14. Sprint budget is calculated to determine how many product backlog items/features can be included in the sprint/iteration.
15. The sprint/iteration ends on the agreed end date.
16. All tasks on the sprint backlog are broken down to a size that is less than one day.
17. Requirements are expressed as user stories and written on a card.
18. The team estimates using points which indicate the relative size of each feature on the product backlog/feature list.
19. The team generates burndown charts to track progress daily.
20. Software is tested and working at the end of each sprint/iteration.
21. The team is not disrupted during the sprint/iteration.
22. Changes are integrated throughout the sprint/iteration.
23. Automated unit testing is implemented where appropriate.
24. There is an automated build and regression test.
25. Stretch tasks are identified for inclusion in the sprint/iteration if it goes better than expected.
26. The Product Owner is actively involved throughout each sprint.
27. All code changes are reversible and it is possible to make a release at any time.
28. Testing is integrated throughout the lifecycle and starts on delivery of the first feature.
29. Impediments that hold up progress are raised, recorded on the whiteboard and resolved in a timely fashion.
30. When someone says ‘done’, they mean DONE! (ie shippable).
31. The team uses the whiteboard to provide clear visibility of progress and issues on a daily basis.
32. The sprint/iteration goal(s) is clearly visible on the board.
33. All user stories and tasks are displayed on the whiteboard for the duration of the sprint/iteration.
34. Daily scrums happen at the same time every day – even if the scrum master isn’t present.
35. The daily scrum is resticted to answering the standard 3 scrum questions and lasts no more than 15 minutes.
36. There is a product demonstration/sprint review meeting at the end of each sprint/iteration.
37. All team members, including testers and Product Owner, are included in the sprint/iteration review.
38. The sprint/iteration review is attended by executive stakeholders.
39. There is a sprint retrospective at the end of each sprint/iteration.
40. Key metrics are reviewed and captured during each sprint retrospective.
41. All team members, including testers, are included in the sprint retrospective meeting.
42. Actions from the sprint retrospective have a positive impact on the next sprint/iteration.

They score 42 of course!

Nice video on using scrum in the real world.  Thanks guys

Agile programming prescribes automated acceptance testing so that tests can be run
often, while facilitating regression testing at a low cost. Nice tool to automate user acceptance testing.

Some aspects of Agile create tremendous value

The people who are successful with Agile realize that it’s not just a set of techniques; Agile is about creating better products, and making the process less painful along the way.

• Agile is about shared responsibility. “Someone is going to design your product, it can happen accidentally, or on purpose.” Instead of an indirect cascade of responsibility, Agile makes developers partners with other people in the organization. Instead of delivering software that meets specifications, developers engage with the rest of the organization in a more collaborative way to create products.
• Agile is about effective communication. By changing the language of product definition from “features” to “user stories” Agile helps people focus on the value the product delivers to real people, rather than the technology used to deliver that value. By bringing people together to play the planning game, Agile makes it possible for developers to ask product managers “what do you mean by that?” and for product managers to ask “this seems easy, why will this take so long?”
• Agile helps you fail quickly. A focus on working code helps Agile projects stay honest. Instead of working for months on something that may or may not work, there’s a focus on providing smaller parts that are available for feedback and refinement.
• Agile is a more humane way to work. Iterative development helps development teams work at a sustainable pace, and stops the death march. Agile development recognizes the fact that human resources are finite, and you don’t get something for nothing. By considering the implications of a user story, developers and product managers can have a well-informed conversation about trade-offs.

Some aspects of Agile cause frustration

Agile’s roots are in the product development world, not the product creation world. A successful product is more than well-executed technology delivered on time. Most Agile techniques (e.g. peer programming, integrated testing, refactoring) are focused on effective development. Many Agile projects are staffed entirely with people who write code. At a company where everyone isn’t a coder, it can be challenging to fully integrate the contributions of business stakeholders, such as executives and product managers and other team members such as business analysts and interaction designers.

• The Agile process does not provide tools to define key business or user experience objectives. A clear product mandate makes it easier for everyone on the project to share the same vision and contribute to a shared objective. Somewhere in the process, it’s necessary to define “What does this product do?” “Who is the customer and what does she value?“ and even “What should the experience of using this product feel like?” Many people assume that these things are determined before the Agile development effort starts, or can be figured out iteratively as development continues.
• An Agile “customer” may not be the same as the “user.” An Agile customer is often the business stakeholder who paid for the project, not necessarily the “user” of the system. When an Agile team does have a chance to show work-in-progress to actual end-users, their feedback can be difficult to interpret or prioritize.
• You can lose sight of the big picture. Developers need user stories to be small so they can be tested and built in a single iteration. Even when a team starts with some idea of the overall experience they want to create, once it’s broken into granular user stories, it can be difficult to identify useful interaction patterns and maintain a coherent product framework. Using Agile techniques, it’s possible to come up with solutions for every user story, and still fall short on making a product that’s a pleasure to use.
• It’s hard to integrate visual interface design. Visual interface designers who produce static pixel-level screen mockups can find it hard to integrate their process with an Agile development team. When responding to the needs of the evolving product it can feel like they are always playing “catch up” and trying to rework visual and interaction design decisions that were made by developers as they built the product. Developers can feel that designs of this nature are “brittle” and that visual designers are not responsive to their needs.

Interaction design can help

These challenges seem to suggest areas where interaction design techniques can help. Interaction designers can partner with product managers and developers to evolve Agile from a development process to a product creation process. Although some people have the impression that interaction design is solely a “waterfall” method, in reality a highly iterative, sketch-based approach to interaction design can be quite nimble.

• Interaction designers can partner with product managers and other business stakeholders to understand and balance business and user goals. Interaction designers can clarify and articulate the product mandate through stories and sketches that create conversation and consensus.
• Interaction designers are experts in observing and understanding user behaviors and making this information available to the development team in the form of personas, mental models and scenarios. Depending on the timeline and project scope, this work can be done in a very compressed timeline, or successively as new insight is needed.
• By thinking about the design problem at a higher level than user stories, (I’ve heard some Agile teams call this a “big story” or a “narrative”) interaction designers can help developers understand the underlying interface patterns and framework of the design and assist with the sequencing of user stories as they are implemented.
• Interaction designers can facilitate design brainstorm sessions where everyone on the team can contribute ideas and jointly understand the implications of design decisions. Interaction designers can also take these varied inputs and create coherent design solutions that people can understand and use.
• By working through interaction problems in low-fidelity sketches, interaction designers can quickly iterate on different design solutions, which helps developers save time and make good decisions.

Actually time sheets are bullshit:
* they demotivate developers
* 10-15% loss of productivity is the minimum
* developers have to fake the time to fill them out properly
* erroneous data is used for reporting and management makes bad decisions
* customers are deceived
* they have nothing to do with quality code production
* they focus the whole organization on phony data instead of production

Nevertheless, this is not enough for many managers to give up time sheets. Just like the waterfall process, there is a psychological dependency so strong, it is as if they are on drugs.

However, the situation is even worse. Most management has completely wrong information in their head and thus continually make bad decisions.

* there is no correlation between developer time and software production
* there is no correlation between time spent and quality of code
* there is no relationship between “quality people” and code production

The only correlation between developer time and quality production code is the quality story points measured as a deliverable for a specific team.

Research over many years provides some of the best data on this topic
* for a single project worst/best coding times are 1/10
* across many projects worst/best coding times are 1/25
* the ratios above are the same for the worst and best Yale students
* the quality of the code produced is completely independent of time spent

For some reason, many development managers makes decisions without any data at all on this issue and their assumptions are completely out of reality.

Trust me, you need to dump those lame time sheets and get focused on real software production before an Agile competitor puts you out of business!

I’ve been looking around trying to find some good advice on how to integrate user interface design into an agile/Scrum process, but I haven’t found a lot helpful, practical material.

From what I’ve seen, there are two primary options:

1. Design as-needed during a sprint.  This is definitely the more ‘agile’ approach, but it can create issues.  Either your going to have to come up with a way to do some very rapid design work (back-of-the-napkin / whiteboard kind of stuff) or you may find your developers waiting for a few days at the beginning of a sprint while your designer comes up with stuff.  This puts the designer under unfair pressure, and may result in your developers twiddling their thumbs.

2. Design one sprint ahead.  In this scenario, your designer will work on design concepts for the next sprint during the current sprint.  This is less agile, but gives your designer some breathing room.  This is helpful if you have designers who are uncomfortable with a very rapid design process.

My preference is option one, but we have found that that introduces too many constraints on the process.  Given that our project priorities aren’t changing rapidly, we can manage this level of pre-sprint work.

Designers fall into the same category as business and quality assurance analysts — no less important than the developers, but they do play a ’supporting’ role, and these roles aren’t expressely prescibed by Scrum.

We at Boulevart have been using the Agile Software Development with Scrum methodology since 3 years. Unfortunately not all our customers take the agile road, so we still have a mixture, although the agile approach is gaining.

After observing some good results, I went to a training workshop to receive my own ScrumMaster Certification, like all our project managers . I’ve brought an Agile Project Management Scrum Methodology to the Professional Services team - an attempt to deliver multiple projects with shifting deadlines and changing priorities. While not completely geared for client-side development work, Scrum has brought transparency of our developer’s day-to-day activities to the senior management team. These are the guys that always seem to think that projects are “easy,” “will be done very soon,” and that our overall work troubles aren’t a “big deal.”

We are pleased with the early returns that Scrum has provided. As soon as the team broke out each project into discrete chunks of work (aka “stories”), the rest of the company started to see just how much work we had to do. Now, if they want to horse-trade and shuffle priorities, they at least know, in excruciating detail, the trade-offs they are making with respect to all other client deliverables.

Turns out that development is a lot of fun after all . . . .

It is often said that agile projects are risk and business value driven - This means that if we take in a bunch of work with low risk - based on the priority by the business - we can focus on keeping and dealing with  the high risk issues in our product backlog. Eventually as the product is being developed more and more of the high risk issues will be scaled down to low risk issues. And why is that? Well, in the beginning of all projects there are alot of uncertainties attached to the individual project. The project team have good and clear goal for the next couple of sprints but after that it gets more and more diffuse.

So if we take a look at the economic risk of an agile project and a traditionel waterfall project, we can see 3 major factors that speaks for themselfs:

- In both types of projects there is a high level of economic risk involved at the beginning of the project.

- In the agile projects you have control as you go - through close contact, communikation and feedback with the customer - you adjust as you go along thereby reducing risk in the project every day.

- In traditionel projects were you deliver the product at the end of the project lifecycle you will not have the same kind of control of the risk, since the customer isnt as close to the product during development.

And if we again look at the cost of changes it shouldn’t be much of a chock to everyone that the costs are very different when comparing the two projecttypes:

- In an agile project changes can be introduce in every sprint - since the customer is close to the project nothing should come as a surprise to them or the project team. So agile projects are all about fast and value creating changes.

- In the traditional project you will soon learn that any changes after the project start will eventually be more and more expensive as time on the project lifecycle passes by.