Deborah Hartmann, one of the contributors to Agile Advice, has started a wiki-based FAQ for Scrum. At the moment, it is bare of content: please submit questions or answers!
So it turns out, in our house, our planning horizon is about one day. Therefore, our one-week iterations were consistently having problems: lots of dropped tasks, but still very busy. As well, the effort of trying to maintain a huge backlog revealed some environmental constraints: we spend a lot of time on yard work, for example.
As a result of these two discoveries, we have moved firmly to day-long iterations. Each day at the beginning of the day we take between 5 and 15 minutes to plan out our days TODO list. Melanie and I each have separate lists. We coordinate our lists throught the master household backlog. Melanie does very well in choosing a TODO list that she can accomplish in a single day, partly because she uses her daily planner to schedule things (estimation). I tend to have a lot of small things fall off the end of my list at the end of the day, mostly because I do not do any sort of estimation or scheduling. I may start.
In my previous entry about Agile Household Management, I mentioned the use of a corkboard. That is no longer being used for tasks. It is now being used for general notices and lists relating to larger tasks. For example, a list of items we need to purchase from Ikea, and a list of repairs we need to hire a plumber to do. My iteration (daily) TODO list is now a piece of paper at the side of my desk.
From the article:
The study found that agility — the ability of the workplace to adapt to change — has emerged as the single highest priority in the workplace industry. The agile workplace needs to be flexible enough to support many ways of working — no one size fits all — and its boundaries need to expand to support work at any time, in any place, with anyone.
The study also examined the effects of the agile workplace. It discovered, for example, that organizational structures tend to be more team-oriented and less hierarchical when it’s easier for workers to collaborate across the boundaries of time, space and geography.
Cause or effect? I suspect that there is a positive feedback cycle at work here. As teams and organizations adopt agile practices, they adapt their workspaces to be more suitable. As the workspaces change, the organization is able to more effectively adopt agile practices.
At a team level this is certainly true in my experience. At first, many organizations adopt agile practices without, for example, having the team sit all in the same room. As the team becomes more proficient at the agile practices, it becomes more and more of a burden that the team is not co-located. At some point, it becomes critical for the team to be co-located if they are to become any more efficient. The organization/team then bends itself to enabling co-location. Once the team has found itself a space and moved in, it reaches a new level of effectiveness… until the next environmental constraint is encountered.
If your work is hurt by some environmental, team or technical factor, there are only a few things you can do about it:
1. Ignore it (not advised). This usually can “work” for a short time, but inevitably leads to greater pain in the future. The only time this might be worthy of consideration is if the team has a larger or more immediate problem that deserves the team’s full effort.
2. Attack it/do it a lot/embrace it. Develop an exceptional skill in dealing with the problem without eliminating it’s root cause.
3. Transfer or expose the stakeholders to it. Be truthful about the situation so that the stakeholders can deliberate on how to effectively address the situation. In this collaborative approach, the team and the stakeholders work to determine the root cause of the problem as part of addressing it.
4. Measure things very visibly. Expose stakeholders to the problem in a factual manner. This method is used where the relationship between the team and the stakeholders is not yet a trusting relationship. This approach can be an effective CYA for both the team and the stakeholders and can lead to greater trust.
Ron Jeffries recently posted something to the scrum developers list, where he made reference to his article on Big Visible Charts. It’s a good article, and looks at a variety of presentations of metrics in an agile project. It took me back to Edward Tufte‘s Envisioning Information
As practitioners and advocates of agile approaches, or as people considering the use of agile, the presentation of real status of an effort is crucial. The more of, and the more creative solutions that we can use to present this, the better we can communicate the real business value that the stakeholders are receiving.
Please try them out! And if you like the system, check out HaloScan.com. And let me know in the comments if there are any problems 🙂
At the Scrum Gathering in May, Mike Cohn gave some good advice about testing in software that applies to all types of Agile Work. A very important Agile Work Practice is Test-Driven Work. If you are applying agile to an existing endeavor, there may be a lot of work already completed which does not have tests in place. This is a testing debt: eventually you will have to pay the principle down (build tests) or you will keep paying the interest (fix quality problems).
1. Start by creating tests that are easy. This is the “low-hanging fruit” and it gives the team a sense of accomplishment and progress against what may be a very large and difficult (but necessary) task. This can be done in such a way that it creates a framework that makes the creation of future tests easier.
2. Add to all new work the creation of tests. This is the move to test-driven work. At this point, your testing debt will now be growing smaller as a percentage of the overall amount of work. This standard must become second-nature to the team.
3. Once all new work is being done in a test-driven fashion, it is possible to start paying off the testing debt principle. The team sets aside a small amount of extra time to build tests for work that is already “complete”. It is important to focus on building tests for the parts of the work that are most likely to need the tests.
For software, the book Test Driven Development: By Example by Kent Beck is an excellent introduction. I would like recommendations for books and web resources for testing and quality in other fields. Please email suggestions to topics@agileadvice.com.
I have not yet read many of the papers on the site, but Paradigm Shift International hosts a substantial collection of essays and links to other work on the topic of Enterprise Agility. The author of the essays, Rick Dove, has been writing on the topic since November 1994. As I read these essays, I will write up very brief reviews with comments about how his thinking relates to Agile Work.
There is a very interesting paper online that presents an Agile Enterprise Reference Model. From the paper:
Sponsored by the Agility Forum, this 1996 reference model project had two principal goals: 1) design a reference model structure that effectively captures and displays the essence of enterprise-wide competency at both proactive and reactive change; and 2) validate the design with a rich, comprehensive example that provides an instructive reference case for an entire enterprise. The purpose is to provide a defining profile with examples for business managers and executives responsible for strategic planning, operational management, and reengineering.
One very interesting part of the reference model is a Change Proficiency Maturity Model. In this model, an organization can be described by its level of maturity in adapting to and creating change. The levels of maturity are as follows (again quoted from the paper):
0: Accidental – Stumble through change, recognition but no awareness.
1: Repeatable – A set of rules for acheiving change become understood.
2: Defined – Rules broadened and performance metrics put in place.
3: Managed – Objectives clarified, rules refined, accountability in place.
4: Mastered – No longer rule based – principles guide action.
There is a logical correlation between these levels and the various aspects of the Agile Work framework. The Repeatable and Defined levels of Change Proficiency match up with the various Agile Work Practices such as Maximize Communication, Self-Steering Team, and Adaptive Planning. The Managed level of maturity matches up with the Agile Work Disciplines of Empower the Team, Amplify Learning and Eliminate Waste. Finally, the Mastered level of maturity corresponds to the Agile Work Axioms: People are Creators, Change is Constant and Reality is Perceived.
As an agile coach, one pattern of activity that I have found very beneficial is to meet up, one-on-one or in a group of three, with individuals before critical meetings. Critical meetings include training, facilitated workshops, conflict resolution meetings, project launch meetings, or any meeting where there is a lot at stake.
Each one-on-one follows a similar pattern. First, basic introductions. Then, I give a very abreviated life and professional history (married with three kids, grew up as a geek, 9 years doing agile, blah dee blah…). I also ask for a brief professional history from the person I am meeting with and if possible, as a little about who they are as a person. For example, I might ask about hobbies, family or what they consider important outside of work. Then, I check on their knowledge of the subject of the meeting. I get a basic background of how they think they might contribute to the meeting. I also find out how much they are familiar with agile, lean and other related concepts. If they are not at all familiar, I give a very brief introduction to agile work. Finally, I ask if they have any thoughts or questions that might be important for the upcoming meeting.
What does all this do? First of all, it allows me to have a personal connection with everyone in the meeting so that I don’t have to try to build that on top of facilitating the discussion at hand. Secondly, it helps map out some of the strengths of the individuals involved. Occasionally, I will encounter someone who has something really unique to offer in the meeting. For these people, I ask them to make a special effort to present their unique skill, knowledge, etc. at the meeting. They may even go on the agenda. Thirdly, the one-on-one meetings provide a potentially safe environment to bring up issues that may be hard to bring up in a group.
I usually budget 1/2 hour for each meeting and they usually start a few days before the main event.
Many large organizations currently operate by creating project teams of people who formally report into other parts of the organization. This matrixed organization is meant to allow people to develop centers of excellence around a specialization and at the same time to implement a system of checks and balances. However, this type of organization also often encourages sub-optimal behavior by narrow performance measures and incentives (narrow to the area of specialization).
Consider using de-matrixed teams if you are finding that people on your teams are having a hard time collaborating, or if people are refusing to do work outside their area of specialization, or if people are doing really well inside their center of excellence but seem to have real problems making projects succeed.
What is a de-matrixed team? A de-matrixed team is constituted by having all members of the team report to a primary stakeholder of the endeavor. It is still possible, and often wise, to maintain centers of excellence, but team members no longer report into these centers of excellence. Instead, the centers of excellence become a source of support for teams that have specific needs (skills, infrastructure, etc.).
Briefly: I have a story to tell of two organizational cultures. In one, called Great Leader Financials, management tends to trust people in the company enough to give them great lattitude in how they get work done. In another, called Rigorous Process Financials, trust all around is low and is compensated for by meticulous processes and documentation. Both organizations are large with many thousands of employees.
At Great Leader Financials, our project team decided we needed to put in place a new server to experiment with some software tools to assist with the work we were doing. One of the team members had recently finished with another project and knew that the other project had a server they were no longer using. He simply contacted someone in management, let them know what was going on, and re-configured the server for our team’s use. Within minutes we had effectively transferred “ownership” of the server from one team to another. Several hours later, the server was set up with the new software and we were able to start trying it out.
Regrettably, in a similar situation at Rigorous Process Financials, our project team identified a need for a server to try out some interesting software tools for our project… and then ran into a huge bureaucratic brick wall. It turns out that at Rigorous Process, you can not just re-configure an existing server. One must follow the prescribed process. Unfortunately, the prescribed process requires getting a budget and project approval. And getting project approval involves going through a very lengthy project prioritization process. And small experimental infrastructure projects are always given a very very low priority. Trying “guerilla” tactics would have fared no better. Simply going out and purchasing a cheap computer (say $400 bucks) and brining it in would have only one effect: bringing down the immediate wrath of the IT Operations people as they detected a new server on the network. At Rigorous Process Financials, we do things the right way, or more likely, we don’t do them at all.
In a recent discussion I had with someone about the Agile Work Axioms, he mentioned that he thought that “people are lazy by nature”. Here is my brief response:
I don’t totally agree. Those who are motivated for whatever reason to do something will be “not-lazy”, and those who aren’t motivated will be “lazy”. But the fact is, that I don’t think laziness is a fundamental truth about human nature. I think it’s a consequence of how engaged we are with our environment, which in turn is a result of both our internal state, and how attractive our environment is. Television is a great example: it is so engaging that we will sit around doing nothing even if it becomes physically quite uncomfortable. Normally, laziness is associated with avoiding discomfort.
In terms of engaging with our environment, the three Agile Work Axioms define a system of engagement:
In January of 2005 I was invited to give a one-hour introduction to Scrum to a college media arts class. The class had one group project: to create a student documentary film on some topic. The instructor and the class used an adaptation of Scrum to manage the work of creating the documentary. Some key features from Agile Work included Self-Steering Team, Iterative Delivery, and Adaptive Planning. The following is one student’s reflections on the project. The student who wrote the following was, during my presentation to the class, acclaimed as the best person to be the Scrum Master.
“The whole documentary process has been an enlightening challenge.
First there was the process to find a consensus on a direction. Possibly the first real challenge as a group. As scrum master there were some great personal challenges. I am not a big fan of teamwork. I see it’s value but I have always worked independently and lived or died by my own efforts. There are huge issues of trust and success when you start with a group dynamic. The trust goes both ways. What if I let the group down because of my health or slower technical skills?? When you work independently you can set your own schedule. Will the pressure of letting down the group be enough to motivate the individuals?
SO the second big learning process for me was to be part of a team.
As scrum master I needed to keep myself focused and everyone on track without being a too pushy. NO one has any real obligation to me or anyone else on the team so setting a manageable pace, problem solving as an individual and as a team was another vital part of the process.
The whole concept of iterations kept things in manageable sections, that was a huge contributor to keeping a manageable goal in site when we were all feeling overwhelmed by the load of all of our courses work. AN interesting observation was that I think there were times when what we were doing in documentary was relatively minor but the fact that we were accountable for it everyday made some people feel overwhelmed. I certainly stand to be corrected but I think because we became such a good team that there was (and still is) a sense of the collective workload.We all improved our technical skills, me particularly. I still have lots to learn but my confidence level is much higher.
There is a lot of respect shown for everyone’s work. We joke about things but people are mostly very respectful of the time and effort people put into their pieces of the puzzle. There doesn’t seem to be a lot of ego attached individually. We are each willing to recognize each other’s strength’s and weakness without rude or critical.
Overall this has been a positive process that is all about teamwork, individual strengths and respect. Garry [the instructor], you have been terrific about leading from behind! There were many times (and still will be) when we know we have a direction but don’t know how to get on the road exactly. You share your professional experience in such a way that we feel like we went searching for buried treasure and made the map ourselves.
I hope to finish the process and keep the momentum to an exciting finished product.“
Sharon
The project was indeed completed successfully! Other students in the class also provided very positive feedback on the use of Agile Work methods.
Collocation of the team is used to improve communication efficiency and to allow the team to learn to be more collaborative. Perfect collocation would have all stakeholders and work performers in the same work space (e.g. a large room) during all working hours. This level of collocation is not usually possible, so adjustments are made.
Collocation reduces wastes associated with waiting, movement, and inefficient communication. Collocation increases learning and feedback and assists with team empowerment.
Collocation can present challenges to people used to working on their own. For these people, a careful consideration of how to accommodate their working style is important, but more important is helping them to understand the need for and benefits from collocation. As this understanding grows and as the team starts to produce noticeable results, most people start to enjoy the close working environment.
When perfect collocation is not possible, consider part-time collocation, video conferencing, having a decision-making proxy represent the stakeholders, getting rid of closed offices, moving into open or shared work spaces or collocating part of the team.
I typically hear a great deal of positive feedback from teams that were previously not collocated after they come together in a common space. For example: “I don’t have to spend hours dealing with email anymore – it takes a few seconds to lean over and ask a question and get a response.” “Meetings that used to take half an hour to organize on people’s calendars now happen spontaneously.” “I can work much more efficiently because the people who I need to collaborate with are right there. No more emails, phone calls, scheduling, and pestering.”
