Two Time-Management Techniques to Aid Agility

Untitled by Eflon via Flickr
Untitled by Eflon via Flickr
Untitled by Eflon via Flickr

Originally published on ScrumAlliance.org

With Agile as a philosophy and Scrum as a framework, ScrumMasters are sometimes on their own, left out in the cold when it comes to specific tactics. While I heartily recommend such practices as BDD (behavior-driven development), continuous delivery, and so on, there happen to be some simple time-management practices that I have found to be beneficial for almost all of my teams that have chosen to adopt them.

Team time facilitates collaboration

As every Agile practitioner knows, collaboration is essential to succeeding in Agile so that all parties can discuss the work that needs to be done. To increase collaboration, most of us facilitate grooming sessions with our teams to do things like pointing, writing acceptance criteria, and breaking down epics.

But there is one challenge many of us face: how to effectively schedule and ensure participation.

From my experience, one useful way is to establish “team time” every day right after the daily stand-up. Every day for my teams it takes the form of 45 minutes after the stand-up, which allows us appropriate time to sprint plan, sprint review, retrospect, backlog, story groom, and maybe tell a joke or two.

One of the major benefits is that every team member knows when they are going to meet in perpetuity, so they can more easily find productive time unburdened by a great number of ad hoc meetings. It also lends a very nice rhythm to their day! Since this (and my other technique, outlined below) is agreed to by the team and its efficacy discussed in retrospective, it’s a great example of how a team can maximize collaboration. I have had multiple teams use this technique over the past few years, and I honestly can’t recall one that did not feel it was beneficial.

“Office hours” allow team members to focus and find flow

Veteran ScrumMasters know that individual team members should not be scheduled for eight hours a day. In fact, most know that getting five good hours in a day would make for a productive day indeed! Besides, if you are using the team-time technique discussed above, then you’re starting an eight-hour day with only seven. But here’s the big question: How can I make sure I can get in those five productive hours a day?

In order to ensure that individuals get the needed focus needed to achieve a flow state, one that is necessary for good concentration and coding, most of my teams use “office hours.” These are time slots, decided upon by the team, when they are available for productive work only (e.g., tasks assigned during sprint planning). They will usually schedule a two-hour block in the morning and another three-hour afternoon block in Outlook (if you don’t use that, then you can use a real calendar! No, just kidding).

Not only does this eliminate disruptions but it is compatible with pair programming or other team interaction work when needed. As with team time, it is rare for a team to try this simple technique and then choose to go back to, as one team member put it, “scheduling chaos.”

Stronger together than apart

To summarize, using team time as discussed is an excellent way to facilitate engagement while also ensuring that the team’s rhythm is unbroken. As well, office hours provide a great, chaos-free environment for the team to buckle down, since the time blocks are clearly outlined. While each technique, in isolation, is beneficial for many users, I have found that team productivity soars when the two are fused together.

To see what this looks like in action, take a look at my example spreadsheet below. This will give you a starting point for your own implementation of these two techniques (and maybe jog some of your own inspiration!). I hope that this makes the Agile road easier to travel, because believe me, the journey is worth it.

Time management example

For additional reading, here are two articles I recommend that touch on this subject:

If you have any questions, feel free to reach out with commenting below or with social media. Thanks for reading!

Larry Apke

Enhanced by Zemanta

Why Project Focused Mentality is Killing Software Development

california damian morys larry apke agile doctor
California by Damian Morys
California by Damian Morys

So, the other day I was listening to NPR in the car (like most people when they listen to talk radio). And the talk was about peace in the Middle East. One of the experts mentioned that, in his opinion, unless both sides owned the process, it was never going to come to fruition. This reminded me of Mark Fritz, international speaker on leadership in today’s organizations, and a compelling blog post he wrote about ownership. I thought this was interesting because there was an interwoven thought he drew upon throughout the post that I believe is applicable to Agile and software development:

“You never wash a rental car.”

I have used a similar phrase many times before when describing the project-centric mentality that pervades most large software development shops. I tell people that, in order to have good quality code, in order to do the right things by the code (BDD/TDD, continuous integration, etc), you must own the code. Therefore, we must move from project to product management, from renting our code to owning the code. So now you know why my brain went from the Middle East to Mark Fritz to rental cars, and now here we are!

Also, I distinctly remember a recent talk when I proposed that in order for better quality products we must eliminate the PMO and replace it with a PPMO (Product and Project Management Office). Interestingly enough, I remember this talk was given to a roomful of project managers who conveniently heard the first part of the phrase and not the second part.

The bottom line is that Agile is about creating high quality software quickly. This cannot be done long term without doing the things that come with owning the code. No project, which merely rents the code, is going to spend their budget making sure that the next group to rent the code has an easier and better time. There is no incentive in project focused organizations to do the right thing! The pressure is on chasing the next bright, shiny object as quickly as possible (e.g: feature chasing) with zero regard for the long term stability of the product.

Before you know it all you have is a big pile of mud that no one can safely enhance or refactor without high chance of regression defects. The time it takes to bring the new, shiny objects to market becomes longer and longer because no one bothered to create the necessary infrastructure. Why not? You might as well ask yourself why no one washes a rental car.

Larry Apke

Message from the CEO: We Must Evolve

The Entrance by nattu, on Flickr Agile
The Entrance by nattu

On the flight home from a recent assignment I fell asleep and had a wonderful dream about a speech that a CEO gave to his employees. It went something like this…

In order to survive long term a species must evolve. So must companies. So must we.

Our company is heavily reliant on our software for survival. These days the new environment of software development is agile. This is an inevitable evolutionary step that we either learn to do or we will eventually perish. There are already a number of our competitors who are further evolved than us but fortunately there are a number who are not. We may be able to catch those ahead but we most certainly must evolve more than those behind. Survival is not only for the fastest gazelle, but we must at least be faster than the slowest.

To date our size has been a saving grace, along with the relative ineptitude of our competition. However, we can no longer rely on either size or dumb luck. We must boldly evolve. The savannah is littered with the carcasses of large and slow companies, ones who were too slow to keep up with the changing landscape. It wasn’t too long ago that Borders and Blockbuster were behemoths and now, they are no longer with us. Those who rely on size would be wise to note that Fortune 500 companies now have a lifespan of 15 years versus 75 years half a century ago, as stated in a Forbes article I read that used the Shift Index.

That is why as a company we must not relegate our evolutionary future to random mutation or genetic drift but instead embrace the values and principles of agile development, the implementation frameworks of scrum and Kanban and the software practices associated with XP, BDD and the like.

I have been told that there have been several attempts to take this company agile in the past but the proponents of these ideas have been thwarted by organizational antibodies such as fear, indifference and outright subversion. My sincerest apologies to these pioneering men and women for not understanding or giving support to your cause.

In order to ensure that our company transformation goes smoothly, I have appointed a CAO, or Chief Agile Officer, to work alongside me. He has my full support and let me make one more thing crystal clear: from this day forward anyone who subverts our essential evolutionary change will have plenty of time to commiserate with former Blockbuster employees.

We must evolve. We will evolve.

Then I woke up. And the speech has not been made and Blockbuster and Borders are still out of business. But I still have hope.

Larry Apke

Silent Grouping – Rapid Story Pointing and Story Value

I have presented in the past something I called Rapid Release Planning. While I stand by this method for teams that have a history of delivery, I have found a much better way for new teams or teams with no previous history of delivery. It’s called Silent Grouping.

If you are interested in possible mechanics, please follow the link above. The only guidance I would provide is that I do not start out by using any numbers. This seems to work much better in that all I ask is for the team to place the stories from smallest to largest. Natural groupings occur when you do this and then you can then use these groupings to draw lines on the board that would correspond to points from the natural groupings.

The real importance is that by utilizing this technique a newly formed team is able to get stories pointed much faster than anything else I have ever found. It keeps people focused on relative size and avoids in depth discussions about acceptance criteria.

More importantly it can be used for other single dimensional relative measures, story value, for example. If you then take these two relative values you can come up with a quick, easy and painless way to see a relative ROI for each story.

The Night Sky and the Tea Koan

As a coach, there are a number of stories that I usually talk about to my new teams to help them understand what my job is all about.

One I like to use with teams that think they already know agile is one I call “the night sky” which I based on my own personal experience. It goes something like this; when I was a kid growing up in the suburbs, I frequently played games outside with my friends at night. Sometimes we would look up at the sky and try to identify those constellations we knew. Most often we found the big and little dipper, but our limited knowledge (and limited view) allowed for little else. Nevertheless, to me this was the night sky.

Continue reading “The Night Sky and the Tea Koan”

Agile and Antifragile

I submitted a few posts months back on Nassim Taleb’s book Antifragile. Recently I heard from Stuart Wray who also made the connection between Agile and the book Antifragile on his blog On Food and Coding with his post Agile is Antifragile. I appreciate his contacting me and encourage my readers to check out his post and his blog.

If you are interested in the original posts from my blog you can find them here and here.