I’ve recently read a little about Personal Kanban. The first exposure I had to the concept was a parent using Kanban as a weekly chore board at home. I’m pretty sure this one was the first. Since then I have discovered many more. There are also many similar methods that have been in use among home life bloggers for a long time. Today we’re taking a look at the Agile Journey from a different perspective. I’ve mentioned before that Agile is an approach or a state of mind more so then a prescribed set of practices. Because of this the Agilist will naturally approach life situations outside of work in an Agile way. The one that sticks out to me the most is the family road trip.
Like many modern American families we have relatives in multiple states. They are concentrated in Minnesota and Colorado. Neither family has the level of wealth that would make this a regular weekend flight. Truth is, even before the four of us all required tickets we didn’t fly it every time. The cost for driving hovers around the 2-3 airline ticket level depending on what stops are planned and what the meal setup is. Non-stop driving puts the trip around 14 hours. (Non-stop includes gas and bathroom breaks, possibly drive-through’s as well.) Driving non-stop is difficult for two adults but becomes effectively impossible once babies, toddlers, or preschoolers are added.
What does this have to do with Agile? Everything. A long spontaneous road trip with no planning and a strictly planned long road trip with no room for flexibility are both impossible with a family. Specifically a family with young children. Continue reading
In our continued attempts to provide the most value to our (internal) customers in the shortest time possible we are always looking at possible improvements to our process. Due to the limitations imposed upon us by the organization as a whole we do not run as a “pure” Agile team. We have borrowed some structure and process from Scrum.
Our processes are something that we do have some ability to change. In a mildly ironic turn of events as I was completing studies for my PSM 1 certification we realized the daily stand-up was not adding value equal to its cost. Continue reading
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.
Projects have a start and finish. For most software projects the project is considered finished either right before or right after it enters maintenance mode. Most of our applications are running in a maintenance mode and have been for a long time. Requirements for these are generally done as feature requests or bug reports. Running maintenance mode in an Agile manner is going to look different from running an actual Agile project.
If we were running the support desk in addition to being the development team I would have us model our maintenance projects after Kanban. The layout would consist of the developers pulling items in from a story collection. This collection would be ordered by the product owner much as the backlog currently is. Hot ticket items from the floor would be dropped into the top of the list.
The changes to our estimation process have been a huge hit. The project manager has been nothing but pleased with the new methods. She used to fear estimation meetings and no longer does. The team all has an idea what is happening now when previously they did not. The business feels they have a better handle on what we can get done in any given amount of time. It has been a good fit all around. With this initial success it was time to look at what else in our process could be improved within the limitations we have to endure.
As a by-product of a failed Scrum implementation a few years ago we work in two-week sprints and have daily status meetings. We had a lot of other meetings though. There was a planning meeting that was attended by one developer, one person from SQA, and both business analysts. (In fairness, one of them is the project manager as well.) These meetings were long and painful for everyone involved. They went through the requested work trying to define what exactly it was. They picked what would be done next. They broke it down to tasks and times after which they assigned it to a person. After these meetings would be another meeting we called a kickoff in which the whole team was invited.
Doing Agile from the bottom up as an internal team is very different then having an external coach brought in by the organization. As our Agile Journey starts it needs prioritization. Not the product backlog, the Agile implementation. Changes have to start small. They are gradual and can only impact this team. For maximum effectiveness benefits are as far-reaching and highly visible as possible. Success or failure is in full view of the organization. Knowledge, planning, passion, and teamwork will stack the deck in favor of success. Success breeds buy-in from above.
To do this alone would be nearly impossible. On a team of four developers I am the most junior. While my overall IT industry experience is on par with the rest of the team, they spent all of it in development roles. For me it has been just under half, with the non-development experience at a different company. Our project manager was let go at the beginning of the year. I was not yet in a position to take on the role and it was given to our lead BA. There was a catch. It become a dual role of lead BA and project manager. This was already a stretch role. The knowledge gained while earning my certification gave authority to my offer of help. The pending maternity leave of the other BA made the need for help painfully obvious.