Our Agile Flavor
Our team is running a little bit Agile in a company that likes requirements up front. We are also doing this as a bottom up shift in thinking.
As previously stated most of the software on our team is in maintenance mode. We are still running our last re-write as a project. It could easily be considered in maintenance, but that has not changed how we work it. Our newest re-write is just getting into full swing. That one is where we are trying hard to run it as an Agile project instead of the mostly stage-gated waterfall that we did before. It remains to be seen how well this works for us. It can be said now that we are using Agile practices on both of these projects.
The project manager and I do have a goal to be as Agile as possible. We aren’t doing this just to make ourselves feel good. We want to deliver the best value to our users that we can as quickly as we can. We are trying to learn from our previous project, which has had some pretty decent re-work, and apply that to this next one. Our conclusion has been to try and run Agile.
In addition to the training and certification that I received the project manager took a class on Agile specifically tailored for business analysts. (Her background and other job function.) The first thing the project manager noticed is that a lot about Agile is relatively obvious to the point she has been doing it a long time. Getting early user feedback results in a better product for the user at release time. Smaller bits of work can be more easily managed than larger ones. Find out from the user what functionality is actually valuable and work on that. While not using any particular framework or methodology to it’s fullest we have been working in a way compatible with Agile values and benefits.
What we didn’t have is a set process. We had been struggling with how to structure our work for a long time. The previous project manager didn’t really bring a lot of organization to the team leaving the then BA and most senior developer to run things. (That BA is now the project manager.) We also had a failed introduction of Scrum during this time.
Looking at our team now we have made significant progress. Agile principles guide the decisions made by the project manager and me. When someone on the team sees an opportunity to improve our process we address it in the context of delivering the best value to the end user in the most expedient way possible. We make product decisions based on the business feedback and not our perception of what the business needs. We have some more defined processes that we now follow. Even better is that we are willing to change them when needed, and have multiple times.
We do not run pure Scrum. We do use some of what it espouses, so we could probably be considered Scrum-but. (With an emphasis that is not on Scrum in that phrase.) We are not cross-functional. There are developers, business analysts, and quality assurance people. Very rarely will we do any work outside of our job description. We have a Project Manager. We also have an Agile Coach.
Our iterations start with a kickoff on Monday morning. Going into this meeting the PM and I will have verified the product backlog as being ready for the team to commit to work. If it is getting low on items with story points we will schedule a backlog estimation meeting. This decision making is done at a short iteration planning meeting. Coming out of this meeting we have a good idea what the team will commit to based on story point values.
At the kickoff meeting the backlog is presented and the team fills in tasks to the requirements. It is generally known who will be the primary on which requirement. Everyone can provide input into how long a task will take but the final call is to the person that will do the work. A lot of discussion is not needed as everyone was involved in the estimation meetings that created the story points.
We run our stand-up meetings on Monday, Wednesday, and Friday. This is a recent change that came about due to the team feeling that nothing valuable was being accomplished in the daily meetings. Our stories and tasks are assigned at kickoff, and we still don’t know how to break them into less than a day sized chunks. We all work within 30 feet of each other and communicate all day. We did have to concede to 20 minutes instead of 15, but it is still an overall time savings. The final stand-up of an iteration is more of an iteration review. Note this is not a demo. Tasks not done yet had been moved forward the previous Friday so this stand-up is usually a very short “yep, we’re still good” before the kickoff meeting which comes immediately after.
The PM and I have come to accept that due to organizational structure and resistance we are essentially running a 4 week iteration with two separate teams. The first two weeks go to Development, the second to QA and bugs. We run it staggard, so when the Dev side is starting 80 the QA side is starting 79. This is because the organization wants to have two week iterations and a single week cycle is something we are not planning to try.
Our big missing pieces right now are user demos and retrospectives. The users do user acceptance testing outside of the path. Our PM and BAs are proxy product owners constantly in touch with the users. (All of our software is for in-house use.) This part is not too worrying. The retrospectives. This is what I am currently working hard to get figured out. We have tried a few different ideas. The big problem is that the team either does not speak to what could be improved or they feel as if we do not have the power to change the problems they see. We tried anonymous surveys for our last one and that worked well. I plan to continue the anonymous survey ahead of the meeting for gathering feedback. The next step for me is getting input during the meeting as to how we improve what the survey finds.
How do you get value that the team really feels out of your retrospectives?
