A while back we started with one-week sprints. For several reasons. We had four-week sprints earlier, but sometimes it was unclear what we were supposed to deliver and what we delivered.
Today we started our third one-week sprint. The start-up meeting took 20 minutes, and was a stand up meeting. Everyone was standing up. In effect it was just a longer Daily Scrum, with more details of what we were going to do and how.
This week is a short week in Sweden, (holiday in the middle of the week, so most people take vacation days to get a long weekend). Thus the one week sprint is in reality 2 and a half day. During which we will be automating the deployment of some of the plug-ins for RemoteX Applications. We have now roughly used half the sprints avaliable hours, and were mostly done. Leaving tomorrow for fine-tuning and testing of the builds we created today.
We started a new sprint today. This sprint were doing some finishing touches to the hierarchies I posted about earlier, and were touching up on filters.
Were introducing logs on some domain entities, allowing users to track changes to the entity and actions related to it.
Hopefully its all wrapped up nice and tight in three weeks time.
When working with long running software projects. The initial stakeholders and developers often leaves before the project is complete, if it ever becomes completed.
As a result, the inital decisions made when starting the project can be forgotten. The experiences that lead to the project being initiated in the first place no longer exists in the team working on the project.
In some cases it can be good to have rotation of the people working with a project, but in in other cases it can be problematic.
Each software product has a problem domain related to it. If the developers on the project change too fast the knowledge of the problem domain can being to wash-out amongst the project members. The more washed out the knowledge becomes the more likely it becomes, that the development effort reiterates mistakes already done in the past. The worst case scenario ending in project failure.
It is important to stress that the reasons why a project is started in the first place should be communicated to new team members. If the problem domain and the reasons for the project is to known by the developers, chances of developing successful software are greatly reduced.
Ive been working on a business plan for a business plan contest recently. It’s the first time that I write a business plan and to be honest, its opened my eyes on many different levels.
Here is a conclusion I came to after mentally going over the RUP project management method in my head. The business plan is like the Vision document of RUP. It forces you to write down the vision and drives your thought towards the feasibility of the idea or project.
I feel that this mental process of formally writing down the vision greatly increases the chance of success of the project at hand. This process of writing down and considering the details of an implementation is something that I do not feel comes natural to the SCRUM setup.
I firmly believe that; if a team has a common view of how software is to be developed. The team can produce software a lot faster.
If not only for the fact that if the team shares a common view of how code is structured, in an object-oriented sense, then the communication cost between the team-members goes down. The individual team-member can figure out how the developer whom wrote a shared resource implemented specific features of that resource.
A common problem for this is that the team has different backgrounds and experiences. Which gives each individual developer a different opinion in how to develop software. Just take the example of the ever old Test-first or Test-last? Test-at-all?
Having technical team-building sessions could help close the gap between competences of different developers over a team.
Here are some ideas for holding technical team-building sessions
A technical team-building should be designed to give the developers of a team a common ground, or reference point, for how to design software.
You could have a mentor come in and have the developers go through exercises to learn specific techniques.
Give the team incentive for having all developers read a specific book. This book could then be used as a reference when having technical discussions. The goal being to establish a common set of principals for how to software is to be designed and developed. Communicate this goal frequently.
If you have a specific developer on the team who is into TDD and similar techniques, a suggestion would be not to have that developer introduce it. Instead have a mentor come in from the outside and demonstrate/teach the techniques. That way the developer becomes a natural source of knowledge for the team. Without risking that the team views the developer as know-it-all.
Ever had problems with the communication between the customer and the development team, due to hot-fixes? Hot-fixes, deliveries that are not part of the planned release cycles are a burden to the entire release process. I personally believe that the cost of the hot-fix isn’t worth it, instead focusing on fixing the bug for the next planned release. Thus not changing the pace of deliveries.
However, sometimes a change of pace in delivery is needed. The pace change can cause severe communication issues between customer and development team, also a part of the increased cost for a hot-fix. But how can this cost be mitigated?
Hot-fix budget
I suggest to have a hot-fix budget, if the customer has immediate problems with a release that has to be fixed outside of the regular delivery pace. Then it is taken from the budget, the budget is communicated cross-team, as a way to illustrate reserved time for bug-fixes. Now you can communicate about the budget.
What happens when the budget limit is reach for the hot-fix?
The current sprint is aborted. There is no point in continuing building software on top of a bugged delivery. The sprint is then restarted when the foundation is stable enough to continue building new features or changes on.
Remember, it is the people that are working with a process that evolves it. Changes to a process should come from a need by those whom work within it.
I firmly believe that this is the only way a process can continue to evolve without breaking.
This also means that when developing a process-aiding-product, it is the users/consumers of the product that know the demands of the process. Since a functioning process is one that evolves the aiding software also need to be able to respond to changes in the process.
Just a mental note.
I had this discussion at work the other day, about teaching your kid the value of money.
Well I have a kid at home, I cant say in the age where I have to worry about it. But what I also have athome is a SCRUM task board.
Me and my girl adds the tasks that we need to get done to the task board and then priorities it into the tasks were going to complete today. We used to have importance, but found that so far we havnt realy had to sort the tasks as more or less important.
So I have this idea to use our setup to teach my kid the value of money. My original plan was that he would have his chores listed on the task board, just like my and my girl have our tasks listed on the task board. We’ll a natural extension of this is task estimation, we estimate the difficulty, or worth of each task and as he completes a task he gets the equivelant or its worth as “Salary”.
