The first thing you might ask me, is Scrum / Agile development and XP the holy grail of software engineering? The answer is: As always “NO”, for each software development technique or tool there are exceptions of when an when not to use them.That said, these are the best software development techniques I encountered so far and I encourage you to read the free e-book Scrum and XP from the Trenches – How we do Scrum.
Some key takeaways
Is there one true way, to do Scrum / Agile and XP and the answer is….again: NO. This book just describes the way Henrik Kniberg and his team do scrum. Do you work on a product with severe quality problems, are you constantly firefighting or miss deadlines more then meeting the deadlines, then scrum might be something for you, if you really complete the implementation.
Scrum / XP teams
Don’t have time for theories.
They don’t write code that will be able to accommodate all imaginable future changes.
They focus on "Getting things done".
Sprints
Are designed to be short and time boxed.
Sprint planning
The purpose of the sprint planning meeting is to give the team enough information to be able to work in undisturbed peace for a few weeks, and to give the product owner enough confidence to let them do so.
Sprint backlog
The sprint backlog to the right is a snapshot of stories from the product backlog. The team decides how many stories to include in the sprint. Not the product owner or anybody else.
XP Programing
Is not only about pair programming, it’s all about: Simple Design, Pair Programming, Test-Driven Development and Design Improvement (refactoring).
Story points
Backlog items are measured in story points. A story point corresponds roughly to "ideal man-days"
Product owner
If the product owner has a technical background he might add stories such as “Add indexes to the Events table”. In that case ask the product owner a set of “but why” questions until the underlying goal is clear, e.g.: “speed up the search event form in the back office”
The team is normally better suited to figure out how to solve something, so the product owner
should focus on business goals.
Assigning importance level to stories is the sole right.
Team
Assigning time estimates is the team’s sole right, so the product owner or other people may not assign time estimates to stories.
External and Internal quality
• External quality is what is perceived by the users of the system. A slow and non-intuitive user interface is an example of poor external quality.
• Internal quality refers to issues that usually aren’t visible to the user, but which have a profound effect on the maintainability of the system. Things like system design consistency, test coverage,
code readability, refactoring, etc.
Poor external quality can make perfect business sense (releasing a better version later) and this quality can be determined by the product owner. Internal quality, however, is not up for discussion. It is the team’s responsibility to maintain the system’s quality under all circumstances and this is simply not negotiable. Ever.
The word “quick-fix” should trigger an alarm in your head… Nothing is more permanent, then a temporarily solution.
Definition of “done”
It is important that the product owner and the team agree on a clear definition of “done”. Is a story complete when all code is checked in? Or is it complete only when it has been deployed to a test environment and verified by an integration test team? Whenever possible we use the done definition “ready to deploy to production” but sometimes we have to
make do with the done definition “deployed on test server and ready for acceptance test”.
Test driven development
Test driven development, which in effect means that the first task for almost each story is “write a failing test” and the last
task is “refactor” (= improve code readability and remove duplication).
Seat the team together
What does this mean: Well, anybody in the team can talk to anybody else without shouting or leaving his desk. Everybody in the team can see everybody else.Everyone can see the taskboard. Nobody outside the team is close enough to be disturbed. And vice versa. What about distributed teams? Well if you really, really haven’t got a choose and some team members work from an other place, use tools that accomplish the rules above e.g. use a skype like tool and leave it open at all times, including camera and audio!
Always coach people, don’t break them into peace’s and don’t coach in front of the whole team!
Some manager work exactly the other way around, breaking people in front of the team and afterwards call this person to soften the edges. Well, this may work for some people, I personally find this counterproductive and most people will give this manager the finger (most of the time in there own minds, but non the less).
Do sprint demo’s
Doing a demo forces the team to actually finish stuff and release it (even if it is only to a test environment). Without demos, you keep getting huge piles of 99% finished stuff.
Do sprint retrospectives
Because this is your best chance to improve. Without retrospectives you will find that the team keeps making the same
mistakes over and over again.
Plan time between sprints
In real life, you can’t always sprint. You need to rest between sprints. If you always sprint, you are in effect just jogging. At the very least, we try to make sure that the sprint retrospective and the subsequent sprint planning meeting don’t occur on the same day. Everybody should at least have a good night’s sprintless sleep before starting a new sprint.
One way to accomplish this is by introducing “lab days”. That is, days where developers are allowed to do essentially whatever they want. For example read up on the latest tools and APIs, study for a certification, discuss nerdy stuff with
colleagues, code a hobby project, etc.
Note: this post will be updated during the next 2 weeks.