At the End of the Day…

One of the principles behind The Agile Manifesto states,"The most efficient and effective method of conveying information to and within a development team is face-to-face conversation." I couldn't agree more! However, for three years, I ran a dispersed team which could not meet face-to-face. Of nine team members, only two were co-located in the same commercial office. The rest of us worked from home offices in Arizona, California (3), Kansas, and Florida (2). When I tell people we were doing agile development and implemented Scrum, an amazing number tell me we were not agile because we were dispersed and thus "in violation of" the above principle. Yeah, right!

This is a principle behind the Agile Manifesto. The Agile Manifesto itself states, "Through this work we have come to value: Individuals and interactions over processes and tools." Individuals and interactions is exactly what we had - a few of the former and a lot of the latter! In a perfect world, we'd all co-locate, someone would get my Diet Coke and rub my shoulders and....well, they didn't specify the kind of interactions!

"Through this work we have come to value: Individuals and interactions over processes and tools. - The Agile Manifesto"

What Others Are Saying

Jeff Sutherland, co-founder of Scrum, wrote an article with Peter Valhansky and Anton Victoroy for the Agile Journal, Hyperproductivity in Large Projects Through Distributed Scrum. In the article, the authors state that one of the"new best practices" is to have "no distinction between developers at different sites on the same team".

There are two critical points in this one statement; "different sites" and "same team". You do not have to be co-located to be on the same team! Everyone was equal despite someone having more familiarity with a particular topic, or a longer background in the field, or better subject matter expertise, etc. We were a team, with no "I". If you are to be agile across long-distances, you must work to break down all barriers and form a team that behaves as-if it were co-located. As ScrumMaster, it was my job to ensure that everyone respected each other as an equal team member. To that end, I have a golden rule for the teams I lead: "You may critique anything, but you may never criticize anyone." In other words, don't make it personal!

"You may critique anything, but you may never criticize anyone!"

Scott Ambler, with thanks to Erich Gamma, John Kellerman, and Ian Skerrett, describes the Eclipse project in "Imperfectly Agile: You Too Can Be Agile!" for Dr. Dobb's Portal. He points out that the Eclipse development team has "managed to successfully deliver six major releases over the years" and that "it has done so on time, every time, by following an agile process." Sounds successful, right? Now, consider that, according to the authors, the Eclipse project is "comprised of 10 projects, with 23 subprojects, and 262 committees working for 15 different companies in 12 different countries". It can be done on a very large scale!

Over on the Agile Software Development blog, a member by the name of Vaibhav posted the article, "Distributed Agile Development -1: Reinterpreting the manifesto". In his post, Vaibhav points out that "the manifesto was put together in 2001; a long time ago by software industry standard." The article goes on to point out that "offshore development (the primary scenario for distributed development) was beginning to gather momentum, but most such development occurred using the traditional heavy-weight development methodologies." Vaibhav gets to the crux of the matter by asking, "How do such teams cope with being almost totally against the spirit of one of the principles of the Agile Manfesto?" Geographically dispersed teams encounter different issues the further the geographic dispersement is. Our team had no communication problems whatsoever. I have heard horror stories about US companies that have contracted with Russian firms only to sever the relationship and find all the class and method names in Russian after taking over the code base. I've also heard the stories of two and three hour meetings every day between dispersed teams just to review code and work out issues that arose because of a misinterpretation of earlier communications (i.e. specs). No one said it might not be difficult, but a large part of being agile is to constantly inspect and adapt. As the ScrumMaster, I always tried to keep the bigger picture in mind and inspect the team's environment working to minimize distractions and disruptions. I tried to let the team focus on the Sprint tasks and jealously guarded them from outside interference while at the same time inspecting their inner workings to see that we were doing everything possible to be moving in a positive direction towards our many goals. The process of inspection and adaptation is never ending and being geographically dispersed only adds to the complexity that you must work to simplify!

Martin Fowler wrote about the pain offshore development inherently brings with it in an article on his website entitled "Using an Agile Software Process with Offshore Development". In the article, he points out "the weak spots of offshore development come from culture and distance with the business. Because agile development works best with close communication and an open culture, agilists working offshore feel the pain much more than those using plan-driven approaches." He concludes his thought on this by saying, "but it's still less pain than the plan-driven methods themselves!" If I interpret this correctly, he is stating that while there is definitely some pain associated with a geographically dispersed team that a co-located team would not experience, it's not only acceptable to use agile methods in a geographically dispersed environment, but preferable!

Distributed vs. Dispersed

One thing that has interested me about the above perspectives is the intermingling of "distributed" with "dispersed". To me, these are two distinctly different scenarios. Dafydd Rees appears to agree with my interpretation (or I with Rees) in the article "Distributed Agile Development" on i.t.wales.com. In the article, Rees points out the definitions of Distributed development and Dispersed development:

"Distributed development: This usually means co-operation between several teams located at different sites."

"Dispersed development: Dispersed development refers to individual developers located separately, working together over a network."

I would have reworded the definition for Dispersed development to something like "refers to geographically dispersed developers working together as a team." What I have been examining in this post then is not a distributed development environment, but rather a dispersed development environment.

In my opinion, dispersed development refers to geographically dispersed developers working together as a team. Therefore, dispersed agile development refers to geographically dispersed developers working together as an agile team.

Co-location, While Desirable, Is Not Absolutely Necessary

Yes,physically being face-to-face is the most desirable means of communication. However, it is not absolutely necessary in order for an agile project to be successful. There are many, many organizations proving this today. What I am looking forward to is the realization by large organizations that onsite presence of the developer is not necessary! After all, if you can make it work across continents, then you can make it work - period.

The productivity on our small team shot through the roof when I sent them all home. They knew it was a privilege, not a right, but more importantly, they knew that the company truly valued them to show them that kind of trust. Believe it or not, there was a significant reduction of distractions (these are professionals with "real" home offices) and they were able to focus in like lasers on their tasks. Now, make no doubt about it, there were things we would have done differently, but co-locating the team is not one of them. No one could argue with our success!

It took a lot of work from me as ScrumMaster to make sure the company as well as the customer were comfortable with the arrangement, but once both saw that the productivity was not dropping off but continuing to increase over time, they were on-board with the arrangement. I took it to be my responsibility as ScrumMaster to ensure that the company and the customer knew on an ongoing basis the continuing high-level of productivity that was coming from the team. I know at least one of my trainers from my Certified ScrumMaster course would argue that this was outside the role of ScrumMaster, but as I'll post later, I believe the ScrumMaster serves all the needs of the team, not just the easy ones or the ones they're best prepared for. I believe the velocity of the team has as much to do with the ScrumMaster's ability to serve the team's needs as it does with the capabilities of the team members! In the case of a geographically dispersed team, the ScrumMaster is a busy individual!

So, the next time someone tells you they're doing distributed agile development, please correct their misuse of "dispersed agile development". And, the next time someone tells you that you can't be agile if you're dispersed....give them some body language to help them understand that you can indeed do dispersed agile development!

Share

No Comments »

This Certified ScrumMaster is Still a Grasshopper

While I do have experience in what did and did not work for my situation, I was having a difficult time trying to find the right way to employ Scrum. I was looking for the right methodology, the proper technique, the right tools, the best framework; in short, all the wrong things.

What is Scrum anyway?
After meeting Victor Szalvay, CTO and co-founder of Danube, who was one of the trainers at my certification class, I started following his blog. In a recent post,Victor called attention to Ken Schwaber's definition of Scrum. Ken's point is that: "Scrum is really simple, barely a process, more a framework. The hard work in using Scrum is fixing the things that it exposes, actually inspecting the things that it makes transparent and adapting to optimize the results and the organization that produces the results."

It Doesn't Take An Einstein To Figure This Out
As Einstein said, "Everything should be made as simple as possible, but no simpler." Scrum itself is very simple. Yellow sticky notes and, as proven by the second trainer at my class Tobias Mayer, black electrical tape are about the only tools you need to Scrum. You can start simple, with four columns on a wall, board, or paper; the Backlog Item, the tasks of that backlog item, the work-in-progress, and what's been completed. In other words, Item (e.g. Use Case or Story), Tasks, WIP, Done. Go Scrum!

The Hard Part of Adopting Scrum
If Scrum is really that simple (and it really can be), then why isn't everyone doing it? The reason is again a simple one: The results which come in implementing Scrum can be really, really, really painful. How is it that such a simple process can produce so much pain? I believe it's another simple answer: Empowerment.

When you empower a Team to do whatever it takes, to make their own decisions, to remove all obstacles from the path to their goals, to set them free to do their work, you're going to feel the pain for awhile. It may be in the form of great discomfort at "letting go" and "second guessing". I know that pain personally. I used to be a by-the-book, and I mean a large book, of standards. I used to personally eyeball every line of code. I would sit on meetings and make the decisions because I felt there needed to be a one-voice, centralized responsibility and control, consistency, etc. After a very ugly and bad dose of being on the wrong side of that for almost two years in a contract, I came away with a very different perspective. On my most recent job, I took the point, but in a very different way.

My job is now to facilitate, to see that the Team has everything they need to get achieve their goals, and to remove any and all obstacles as quickly as possible. The daily decisions of implementation are theirs. I even took another step in empowerment recently by turning over every administrative password to every server to every team member. They need the flexibility to get their jobs done. Has there been pain in implementing this process? Absolutely! Would I willing go through the process again if I had to? You bet, no questions asked, in a heartbeat!

I'm currently managing several Department of Defense (DoD) contracts in my work at MTS Technologies, Inc. This Team, in just under two years, has built a robust, open, flexible, extensible Medical Knowledge Management System for the Navy and Marine Corps (NMKMS or NavMedKMS). There are still a lot of political hurdles and challenges, but we have made a significant contribution! The system is currently staged with the 1st Marine Expeditionary Force and the Army recently stepped up and requested the system for their own evaluation and use in-theater operations. As the Army put it after their initial evaluation, "you just put us two-years ahead of our own schedule." Would we have received that praise if we had not empowered the Team? Perhaps, but considering that there are several other initiatives who have done this or tried to do this in a centralized fashion without using Scrum, I honestly do not believe we would be where we are today.

Pain free Scrum
Now that I look at the Team's progress and Ken's statement, I can state without reservation that the pain is not in the Scrum process. The pain associated with Scrum is in dealing with the issues exposed by empowering a team to do whatever it takes to accomplish their job. Scrum itself is painless and once you've been through a few Sprints, the pain greatly diminishes as others begin to understand what to expect and productivity can go through the roof. It's well worth the effort, IMHO, to implement a Scrum process. Once you've empowered individuals to come together as a team and stood behind them with full and unwaivering support, there's nothing they cannot or will not accomplish! In a few short Sprints, you can be relatively pain free and Scrumming with the best of them!

Share

No Comments »

Binary Estimation

Estimating work has always been painful for us. How accurately can you estimate the number of hours you expect something to take before you've had an opportunity to fully investigate what's involved? You don't; you take a SWAG (simple wild assed guess). I've always wondered where the value is in that. Pick a date, any date! Pick a number, pull it out of the air -- there, that's our target! I've been on way too many projects that use this as their method of estimation.

The first idea to come to light from my training session was that estimations really didn't matter. In the end, you're either done or you're not. It's simple; binary - 0 or 1, true or false. You don't get partial credit for being "almost there". You're either done or you're not. So, in the daily scrum where you're using a board, what you want to see is someone move the tasks they took on the day before from the work-in-progress column to the completed column. Now that's exciting to me! You can easily see progress, you can see the team stay motivated to make things happen and it's simple to see impediments. All it takes is breaking backlog items down into tasks that take no more than a day.

No task too large...
Is it possible to break everything down into tasks that take no more than a day? Sure, albeit some backlog items may have many daily tasks, you can still break down what you expect to do into a day. So, at the planning session, you create entries for each day you expect to spend on a backlog item. By striving to be specific in what you're going to accomplish with each task, you can break a product backlog down. Some tasks will not take a day - that's fine too. The goal is to break this down into manageable pieces whose completion convey the progress of the team. That way, without much effort, you can get a realistic sense of where a project is at any point in time. Each day, a team member can sign-up for one of those tasks and the following day, they can move the task to completed or identify the impediment which can be quickly dealt with.

We implemented this upon my return and I've been very pleased with the results. It's challenging to get the daily tasks accurate at times, but it's great to see the team step up and help someone out when their daily task can't be moved because it's too big or needs additional definition.

Visualizing Progress with Scrumworks
Where Scrumworks helps with this is in it's Scrum Details window. What we've gone to is a daily scrum where the ScrumMaster opens the Details window. Each team member is then capable of marking those tasks they signed up for as completed or done. With the hours at zero, and the attribute set to not show completed tasks, everything completed falls off the list. Now we can focus on the remaining tesks. These are all "unspecified" for the point person. Each team member then signs up for what they will complete that day. Now, we have a list of what will be done by the next day's scrum and we have all tasks that remain (the unspecified point person). Simple, elegant, and very meaningful. With the binary system (0 or 1), we can see immediately how many tasks remain which we expect to take a day or less. This is very helpful in determining as we move through the Sprint where we stand in the burn down. Again, a very useful and now easy to see and understand metric!

Share

No Comments »