Unless things go sour in a project, a team rarely gets downsized. On the contrary, new team members are often added in the hope that more will get done.
What if sometimes, the best action to increase productivity would be shrink a team? I can think of two situations where reduced staffing is a good option:
The team realized that it grew too fast. Core team members do not have enough time to effectively coach the rookies.
A new features requires an overral architecture change. You can already predict that merging will be hell if new features are added while others are implementing the new architecture.
It’s not always feasible to remove team members – and it’s always a though decision. If the team grew too fast, you might not have any other choice. If you want to do it because you need a big architecture change,Â it might be possible to shift some members to another module or to start something new that will have no impact on a problematic area. You might also try to make the change coincide with half the team going in vacation (I’m sure many of you felt more productive when most of your team was away).
Next time you’re stuck and have a hard time finding effective ways to make the whole team work together, consider a reduced staff for a few weeks. It might be just what you need.
We’ve had enough. We want demos that are fluid. We want demos that are fun. We want demos that work.
So my team tried something which we called ‘Demo Driven Development’ during our last sprint.
In every one of our stories, we included a task called ‘prepare the demo’. This task was only scheduled to take an hour. We just wanted to make sure the story could be demonstrated. The team also named a demo champion (me) for the iteration with some reserved time to prepare the demo. All these tasks were included in our sprint backlog.
The results were pretty good. The demo went smoothly for the most part. I did a small blunder that broke the flow a bit (sorry team) but feedback was positive during the retrospective. The team decided to keep doing the same thing for another sprint, just to see where we’d go.
To me though, the biggest change was not the demo itself but the awareness demo driven development brought. Every time I worked on a user story, I was thinking about how I could show it. The end result was that the feature was just a tad more configurable. One particular story didn’t have a UI so I made logging more readable and complete because I needed people to be able to understand what was happening.
The code was more or less the same. But the feature was better.
Some of you probably think that every story should be coded to be demo’ed anyway. You’re right, it should. But we wanted to improve in this area and it worked for us. Maybe Demo Driven Development is for you as well.
I’ve been pretty busy these past weeks starting a new project.
Since we’ve all followed Agile methodologies for a while, we wanted to have a definition of what ‘done’ means for the team.
A definition of done is useful when you want the whole team to agree when a feature is finished. It can include a mandatory code review, documentation, minimum code coverage, executable specifications, end-to-end tests… It should contain everything you need to do to get some high-quality code.
Although every one on the team is experienced, we’ve been struggling.
We all agreed that we needed to define what ‘done’ means. The content of some parts is still under discussion.
It wasn’t hard to agree on a few things:
We use Domain Driven Design for our domain as much as possible
The domain and non-gui modules need to be unit-tested as much as possible
We have a test map saying which kind of tests should be done for each modules (unit, integration, end-to-end)
We need to document our module and architecture so others can join the project with too much ramp-up.
However on the GUI side we are still debating:
We have a GWT application and we had no experience with the framework.
GWT tests are slow by nature so we try to write relatively few of them. However for the tests we do need to write, we do not know our test coverage yet as cobertura does not seem to support GWT out of the box. It looks possible to use Emma instead of cobertura to get the coverage reports we want. However as far as I could see this would require us to patch GWT. We haven’t tried it yet. It would help if we could find a simple tutorial instead of patches that need to be applied to specific revisions of the framework.
End-to-end tests is an issue. Some people think it’s too early to use tools like Selenium, others think it’s past time.
Do you have experience with a project using GWT? What did you test? How? I’d appreciate if anyone could share their experience.
I read a few articles lately that claim Agile is basically a magic bullet that will allow you to have greater productivity in a few weeks. Well a few weeks is too long… Here is my magic recipe to be Agile in a day. It just requires a little preparation:
Have a definition for a work item that is ‘done’. Were coding standards followed? Is the feature tested? Is it documented? Is it installed in a demo machine?
Plan the release of the product with the main features and an approximation of how big the whole thing is going to be.
Plan the work for two or three weeks at a time.
Make the team take responsibility for the work to be done in the next iteration.
Test everything you do thoroughly (unit tests, end to end tests, and anything you feel is required in between).
Know the difference between a stub, a mock and a fake for tests. Know when to use each one.
Have a continuous integration build.
Name your classes with words the customer will understand as much as possible. Programmers and customers understand each other better if they speak the same language (DDD).
Have a good knowledge of object oriented design.
Fix your bugs as soon as you find them.
Refactor early, refactor often.
Pair program when you can.
Organize code reviews.
Have a customer on site (or at least readily available) so you can question him about the requested features.
Demo your product at the end of each iteration to get customer feedback.
Ship! Release your software to some users early and often to get even more feedback.
Integrate the feedback into your next development cycle. If the customer changes his mind because what he saw is not what he expected, do not be afraid to recode entire features (but make sure the customer knows he will not get new features in the meantime).
Hold a retrospective at the end of each iteration. Identify the biggest problem you currently have and take steps to solve it.
Follow up the retrospective with concrete actions to obliterate your problems. Retrospective are useless if you talk about the problems but do not solve anything.
Always strive for higher productivity. “We always did it like that” is seldom a good reason not to improve.
Allow failures. Expect the team to fail from time to time. Never failing might mean the team is aiming too low.
Do all of the above for a few sprints. The longer the better. If you can do all of the above for a year and still continue to ship valuable software for a customer while maintaining clean code, there is a good chance you can continue to do it for a long time.
That’s it for the preparation. Now, here’s how to be Agile in a day:
Read a book about Agile methodologies. Realize you’re already pretty good but you still have a lot of room to improve. Claim that you are now Agile.
There’s no shortcuts, no magic bullet. Software development is hard. Agile software development even more so. Do not expect every programmer you meet to thrive in a dynamic environment where everyone must take responsibility for their work. Agility is not for everyone. I believe it is the most enjoyable way to build software, but I’m aware that a lot of work lies ahead.
So can you be Agile in a few weeks or less? Well if you are already doing almost everything in the list you probably can. If you do not understand why the list is important, you’re far away… Claiming you can be Agile in a few weeks might be a nice commercial gimmick but that’s about it…
I’ve been interested about Agile methodologies for a while but until recently I’ve never been on a project that really embraced iterations and change. e did try a few techniques (daily meeting, poker planning, task board for the iteration) but it did not really work at the time, possibly due to a lack of successful evangelism on my part.
I just finished working on a third sprint in a Scrum project. And this time, it just worked.
The team was interested in the new process, the client was often coming to see what was going on, the ScrumMaster was great at explaining the process, the artifacts (product and sprint backlogs, burn down chart), the meetings and why we were doing each of them (daily, demo, retro). Some people were not familiar with the process but a quick and clear explanation of the next step kept everyone interested and in focus.
Here is what went right in this project:
Preparation – the client and a few team members prepared a product backlog, rough drafts for the look of the user interface and a little bit of useful documentation.
Collocation – everyone was sitting a few feet away from each other
Quick wins – first sprint of one week delivered a bit of functionality while developing the build tools and test structure. This allowed the team to get a feel of what an iteration feels like (we did the planning, demo and retro as usual) while getting our build, continuous integration and test framework underway.
Client involvement – on site two days a week, not changing his mind in the middle of the sprint. Would it have been better if the client had been there five days a week? Maybe, but two days is a lot better than nothing!
We shipped! We did have a few hiccups, but overall we did ship working software and the client was happy with it.
And how did people feel about our ways of working? I can’t talk for everyone, but here are a few things that I liked:
Commitment– I believe everyone wanted the project to succeed and did their best.
Openness – pretty much everything was open to discussion, including the architecture and the features the client wanted.
Pride – for me this was a big one. I was proud of what we achieved and proud of the team.
Fun – need I say more?
A few things could have been better:
Lack of focus – we had a tendency to work on tasks on many stories and closed most of them at the very end of the sprint.
Adaptation – our retrospectives allowed us to highlight a few points that we wanted to improve but we did not really address those in the following sprint.
Although not a silver bullet, iterative development sure give you all the tools to run a successful project. A motivated team will perform better and what better way to motivate people than to give them the power to improve and select their own tools and processes?
You are in the middle of a great brainstorming session with your new team. Ideas are flying, everyone participates when you hear a ring. You hear in a hushed voice: “Sorry honey, I’m in a meeting, I’ll call you back.” Everyone stops talking to look at the culprit. The flow is broken. It takes a few minutes for the team to pick up where they were before.
Having a set of working agreements with your team can help to prevent this (and other) situations. Working agreements are behaviors that regulate all interaction between team members as decided by the team itself. This is very important: teams that decide their own rules are more likely to follow and enforce them. The act of deciding gives the team a sense of ownership. Working agreements can be discussed during a retrospective or if you don’t do retrospectives (which you should), I guess you can do another meeting for them.
Once a team decided their own working agreements, it becomes easier for everyone on the team to enforce them, not just the project manager, team leader or other authority figure. â€œI did not appreciate when you were late to our pair programming session earlier todayâ€ is not understood as complaint about oneâ€™s behavior but as a gentle reminder of the rules the team agreed with.
Here are some examples of working agreements:
The time everyone is expected to be at the office (9am-4pm or whatever fits your team). Outside these hours people have to be aware that some might not be available for meetings
Usual lunch time (same principle as above)
Time of daily meeting
Meetings should begin on time
Cell phones should be turned down during meetings
Only one person at a time can be mad (I really heard about this one, it’s supposed to allow people to vent while preventing others from shouting back…)
Working agreements can also be more fun:
The person who makes the nightly build fail has to bring breakfast (pastries, donuts, fruits) for the team
The person who makes a build fail is awarded the ‘Cow of Shame’ (or any ugly figurine) until someone else breaks the build
If the ‘Cow of Shame’ is ugly enough, your teammates will run the tests twice on their machine to make sure everything is green before committing their code… and so will you.
Thoughts about programming, technology and agility