-
Notifications
You must be signed in to change notification settings - Fork 82
Agile Project Execution
Some words before. Out of real life experiences we decided to change our project planning/execution to be more agile. There is no standard agile way that fits all. So instead of following a plain text-book approach it is important for every agile team/project to evolve over time. There are however, certain paradigms and techniques that are well spread in the agile community. Thus, since we are at the beginning of our journey to become more agile (note, that per definition this journey will never end), we will follow a text-book design from "The Agile Samurai". This only the first book related to this topic. More approaches will be probably tested and refined over time so stay tuned.
The first really important information for everyone to understand is: There is no I. There is only a we. We as a team decide... We as a team implement... We as a team request... etc. A single person can only provide as much value to the whole project as the entire team understands it. Otherwise, there is no knowledge transfer. Nothing that will be sustainable. But that is exactly what we want!!! Also it is very beneficial if the team is co-located.
Here is broad description about typical roles in an agile team.
- The agile customer: "source of truth", for whom the software is built
- The agile analyst:
- The agile programmer:
- The agile tester:
- The agile project manager:
There is no clear role that anyone in the team has. Every team member should be able to perform any of the role's tasks described above (except maybe the product owner which has a very specific role).
Who is involved in the project but not necessarily permanent on the team but a great deal of the project depends on them anyhow?
- IT: The IT is responsible for a working infrastructure. They are responsible for server health and accessibility. They can provide additional build resources. They are responsible for installing latest compilers etc. So it is important to see them as part of the project team.
Need to be decided by the team!
Estimating the amount of work is the hardest task within every project and most often people fail to give correct estimates. The key point is that we do not estimate person-days or person months but we estimate relatively using story points. We will start with 3 story points: 1 - 3 - 5 1: easy task (within 1-3 days) 3: intermediate task (within one week) 5: heavy task (within one iteration)
If the team estimates something higher than 5 - it will become an epic. A story that the team needs to break down and will take longer than one iteration to be finished.
How to estimate: By reference. We take examples we already completed and use those as relative estimates for 1,3,5. Also in the sprint planning meeting the team plays estimation poker. [TODO] write me
"As a [persona]": Who are we building this for? We’re not just after a job title, we’re after the persona of the person. Max. Our team should have a shared understanding of who Max is. We’ve hopefully interviewed plenty of Max’s. We understand how that person works, how they think and what they feel. We have empathy for Max. “Wants to”: Here we’re describing their intent — not the features they use. What is it they’re actually trying to achieve? This statement should be implementation free — if you’re describing any part of the UI and not what the user goal is you're missing the point. “So that”: how does their immediate desire to do something this fit into their bigger picture? What’s the overall benefit they’re trying to achieve? What is the big problem that needs solving?
Good stories:
I - Independent: The user story should be self-contained if at all possible to avoid dependencies on other user stories. N - Negotiable: User stories can always be changed or rewritten up until the point of coding. V - Valuable: A user story represents a goal of an end user or purchaser and should deliver functionality that is deemed valuable. E - Estimable: You should always be able to estimate the size of a user story. S - Sizable: User stories shouldn’t be too big or too small. T - Testable: User stories must be testable in order to ensure that development is complete and has been done correctly.
What if there is no user involved?
Well, there are different opinions to that. In general there is no "this is the right way to do it". In general the user story subject can be anyone related to the problem. So if it is a story about a technical internal project related thing you can write from the perspective of the subject that will benefit from it.
Like I as a library developer want to refactor the alignment matrix policy such that it abstracts away the banded and unbanded matrix implementation in order to faster implement the vectorisation of it.
This can be also formulated as a Feature-Driven-Design card, which follows the pattern: [action] the [result] [by|for|of|to] a(n) [object]
Refactor the alignment matrix policy to abstract banded and unbanded alignment matrices and make the adaption to the vectorisation faster.
Are defined by delivering something of value at the end of every cycle. Require well formulated user stories. But the in depth-analysis of the stories is first done at the latest point before the iteration it is worked on. Start with a 2 weeks iteration phase. Ensure a tight feedback loop with the customer. Ultimately, they decide if there are changes to the plan once they got the first things to work with!
Who should participate: The development team, The product owner, optimally the customer Just-in-time analysis of the next stories on the backlog with the highest priority. Update the plan accordingly
Who should participate: The development team, the product owner, optimally the customer The team decides what they can take on in the next iteration and stays flexible in this time. Vacation, workshops, conferences, etc.
Review team's velocity Review upcoming stories Decide what is getting into the next iteration Give a quick whether forecast: How is the project health. How are we doing for the release etc.
10 - 15 minutes: Where are we kicking butt and where we need to impove
Demonstrate the user what the new features can do. Some ideas I have are: make small things visible via twitter/blog entries. Organise maybe 4 times a year a meetup and invite people to demonstrate the software more elaborated. Using the developer/user workshops.
Update of your current work progress. Mostly focus on something that is interesting for the team. For instance I thought I can do it like this but it turns out there is an issue with this etc. So focus more on the stuff that you have problems with. Also maybe follow this template:
- What you did to change the world yesterday
- How you are going to crush it today
- How you are going to blast through any obstacles unfortunate enough to be standing in your way
- probably trello
- Visualise in Github
- The stories we planned for the release (in the story gathering workshop)
Visualise in GitHub
- The items we are processing in the current iteration.
ZenHub has great toolings to help us to setup the boards for a clear visualisation.