The Manager's Role in Agile

By Lyssa Adkins and Michael Spayd

What role does management play in the agile world of self-organizing teams? What is the function of managers in this new world? What does an agile organization need from its management team? Where should the agile manager focus their efforts for greatest benefit?

In a general sense, an agile manager is responsible for the “gray area” surrounding agile teams and throughout the organization.

This gray area can be divided into three large categories: managing teams, managing investments, and managing the organization’s environment. Within these three categories, eight clear competencies have emerged from our research and experience with fully engaged agile managers. These competencies can be mapped to the categories as follows: (Note: the meta-competency, organizational change, applies to all three categories and is listed and discussed separately.)

Continue reading this article

The Accidental Scrum

By Paul Jackson

Scrum (and agile for that matter) is a common sense approach to project management that we have all probably used, maybe without calling it Scrum, to manage a project at some point in our careers.  Case in point: a few years ago I joined a Royal Navy Warship as the Logistics Officer.  I had been a software development project manager for a few years, but this was an operational posting, which is inherently different.  I joined the ship in Portsmouth after she had returned from a lengthy deployment. We were scheduled to spend several weeks in recovery and maintenance before returning to sea.  It should have been a quiet time to take over the department. It turned out to be quite the opposite.

Four days after joining the ship, the commanding officer called his senior management team to a meeting. He informed us that we had been tasked to protect the merchant fleet sailing to support Gulf War 2. Our mission: to protect the fleet as they transited the Straits of Gibraltar. Over 100 ships were expected to pass through the Straits over eight weeks. We also had a confirmed terrorist threat, so we had a real job on our hands.  The CO told us we had five days to prepare the ship to deploy. As you might imagine, the Logistics Department had a massive role to play in readying the ship for deployment. We needed enough provisions to feed the ship’s company for ninety days, the right spares onboard, and sufficient sterling and foreign currency to see us through.

At this point in my career, I knew nothing about Scrum. I did, however, have a good idea of what it would take to ensure that we would be ready to deploy. In my short time onboard I had already identified the “movers and shakers” within my management team. I called them to my cabin and briefed them on our new assignment.  I told them to develop their deployment requirements and work out their daily priorities for the five days remaining until deployment.  I gave them our goal and sent them off to prepare their teams. They were to report back to me at a daily meeting, which we would hold every day at 0830 in the stores office. At that meeting, each manager would have two minutes to update us on progress and issues. At the end of the meeting, I would summarize with a redefined goal for the next twenty-four hours.

After our initial meeting, we met each day at 0830. As planned, each manager briefed on what they had done since we last met, what would be achieved in the next twenty-four hours, and what impediments stood in their way.  I undertook to move their obstacles and briefed the CO on progress at our daily Command Briefings. We sailed five days later, fully prepared and ready to meet our mission.

Without knowing Scrum at all, I had set a sprint goal (“We have to be shippable, quite literally, in five days.”), developed the product & sprint backlogs (our deployment requirements and daily priorities), and established a daily scrum. I knew intuitively at the time that we had to come together at least daily to monitor progress and that any issues affecting the sprint goal had to be resolved by me, so that the team could be left to deliver. Now I understand that what I was doing was setting up daily scrums and acting as ScrumMaster for the team.

What seemed like common sense to me when I employed it on the ship turned out to be a methodology that is being put to work in more and more software development organizations each year. Whatever you call it, Scrum delivers.

Implementing Scrum: 8 Questions to Answer Before You Begin

By Srinivas Suravarapu

For the past eighteen months, I have played a key role in my organization's Scrum implementation. Fortunately, I have been coaching people and practicing Scrum in an environment where people are keen to learn new practices and are open to making changes. I have based most of my ideas on that of Ken Schwaber and Jeff Sutherland. Ken and Jeff emphasize the fact that Scrum is a framework and not a methodology. As I considered this after my ScrumMaster course, I decided to implement and coach the team on Scrum as if it were a natural evolution from our current process. To do this, I listed eight questions that I felt must be answered correctly in order for us to make a successful transition. I firmly believe these are questions every new ScrumMaster/Coach should ask prior to implementing Scrum because the answers determine whether your team can succeed with Scrum.

1. Does Scrum fit the bill?

The ScrumMaster should understand, and more importantly be able to visualize, how Scrum aligns with their organization. The ScrumMaster will need to work with management to identify existing problems and brainstorm ways in which Scrum will help them find solutions.

2. Does management believe in Scrum?

Once the ScrumMaster and management have identified how Scrum will work for their organization, the ScrumMaster must himself believe, and also convince management to believe, the following key tenets:

• Software development is best implemented via an empirical rather than planned process.
• Once organizational impediments are removed, a self organizing team will naturally deliver better software.
• You can deliver valuable software within a prescribed time and budget.

3. What functional specialists does the development team have?

Once management has been convinced, the ScrumMaster needs to identify the functional specialists in the development process, such as developers, testers, analysts and managers. (You could identify more; I have just named a few).

4. How can I cater my coaching to the specific needs of each functional group?

The ScrumMaster is responsible for coaching each functional group by concentrating on how each functional group will fit into Scrum and benefit from it. The ScrumMaster should explain any changes that will arise from implementing Scrum. Each functional group needs to be educated on the benefits of using Scrum; no questions should be left unanswered. At the end of this process, functional groups should be convinced that Scrum will work for development. If a team member, in spite of exhaustive training, is unable to buy into Scrum, the problem should be escalated to management. Organizational behavior is key to the success of Scrum.

5. Does the coaching recognize cross-functional teams and coordination?

Once all functional groups are able to comprehend and understand their role in Scrum, the ScrumMaster must bring the functional groups together and coach them on how they will work as a cross-functional team.

6. Does the team understand the difference between a leader and a manager?

It is important that the team understands the difference between a leader and a manager. The team should not report to the ScrumMaster; the ScrumMaster is a leader who guides the team, not a lead in the management sense.

7. Does management understand the difference between team roles and management roles?

Scrum roles are functional job descriptions; they are not part of the organizational hierarchy. Management needs to clearly isolate hierarchy and any decisions relating to these from the team. Teams need to understand that management reserves the right to manage the organizational structure and that scrum roles are for functional purposes only. Perceptions of ScrumMasters as team leaders or development managers could create a bottleneck right at the start for the ScrumMaster. In these cases, management needs to step in to more clearly differentiate between an organizational title and a team role.

8. Does the team know what kind of engineering processes are required?

Once the functional groups have been transformed into cross-functional teams, the teams should be able to brainstorm on the engineering processes required for iterative software development. Processes might include continuous integration, automated testing, process templates, and so on.

Once a ScrumMaster has coached his team to this extent, the real execution of Scrum can begin.

Pink and the Brain

By Manoel Pimentel Medeiros

Pinky and The Brain is a cartoon about two mice (Pinky and The Brain) who are opposites in nearly every way. The interesting thing about this cartoon, and why it’s relevant to software development, is the struggle between the key characters. I will use them to illustrate the ideal of balance between technology solutions and simplicity.

First, let’s learn a bit about the characters. For those of you unfamiliar with Pinky and The Brain, The Brain (the short mouse with the big head) is the thinker. Pinky, the taller mouse with the big smile, is a goofy jokester. The Brain has a high IQ that he uses to plan and create highly complex solutions to simple problems, often much more complex solutions than are needed. For example, when asked to invent a device for drinking lemonade, The Brain’s solution would likely be a super engine with hydraulically driven pressure tubes, initiated by a solar energy collector and stored in a thermo-nuclear device. Brilliant, but perhaps a bit too involved. A simple glass might do just as well.

The Brain makes some of the same mistakes we make in software development. How often has an analyst or software architect established a super-sized project, using various combinations of technologies and techniques, just to create a simple screen to access a database? It’s not that his solution is wrong; it’s just too complex and risky for the problem at hand. I am not speaking only of the complexity inherent in combining technologies and techniques; I am also speaking of the complexity in fully understanding how the technologies work together, which can kill the productivity of the project.

Then there is Pinky, who believes in everything that The Brain says. Unlike The Brain, Pinky’s tendency is to simplify things. By using his intuition and doing the easiest possible thing, he inevitably achieves more effective results, with less effort, than The Brain. Pinky represents those who prefer simple and easy solutions to software problems. The flip side, though, is that these same individuals might lack the vision necessary to solve problems that require a more complex or scalable solution.

Neither Pinky, with his overly simplistic view, nor The Brain, with his exaggerated complexity, is a model to follow in our approach to software development. Instead, it is important to note that the characters perform optimally when in partnership, balancing an intelligent solution with a simple approach. Too often, we design a spacecraft when we really only need a simple car. At the same time, if we limit the design of the car too much (not giving it a large enough engine, perhaps), we run the risk of over-simplifying the problem. Solutions that lack vision can be just as detrimental to the success of a project as solutions that are overly complex.

Remember, too, that in software, our solution must be aligned with business rules in terms of the scope of the application, and that any solution should enable the implementation of changes or updates that will allow us to adapt to the progressive needs of the customer.

Know the technologies, seek knowledge, and explore possibilities, but always remember that a project is an investment and that all parties want to have good results. Whenever possible, make simple solutions the priority. By doing so, you reduce the complexity and the risk of failure. Striving for a balance between complexity and simplicity will maximize your level of productivity. Use technology as it was intended: to help and not harm you. Think about it!

Two Tips to Help Product Owners with Release Planning

By Lyssa Adkins

Tip 1: Don’t let dependencies dictate when your team delivers value

Things have been going fairly well on your agile team. The team has been producing value at a regular cadence; the team members are actually working together and producing more than the sum of their parts. The team has a good idea of how much it can get done in a sprint (its velocity). The team is now asking, “When does this end?” or “When are we going to release this stuff?” or “I know we’re going to California together but I’m not sure if we’re getting there through Texas or South Dakota.” As the product owner, what do you do next? It’s time for release planning.

Hopefully, your agile coach has experience with release planning. If not, stop reading right now and bring in someone who has done this before. Release planning is not something one can learn solely from reading a book or article.

Let’s assume, though, that your coach knows what she is doing. She walks the team through release planning, so that the team members understand what they are building, have calculated the team's velocity, and have sized all the stories in the product backlog. The team members are feeling good because they now understand what work is left – they at least know if they’re going through Texas or South Dakota on their way to California. But the work of release planning is far from done. One large piece remains: choosing which stories go into which sprints.

Here’s the basic idea: stories are added to sprints until the sprint is “full” based on the team’s known velocity. How do you determine which story goes into which sprint, though? The most important consideration is business value. The goal of agile is to deliver the highest business value items first. This requires you, product owner, to order the stories according to business value. A great discussion of how you determine business value can be found in Mike Cohn’s Agile Estimating and Planning.

Let’s assume you have ordered the stories in terms of business value. Next, lay your stories into sprints starting with the highest business value story first, then the second highest, then the third, and so on. It is important you do this step first, without letting any other considerations influence the order, so that you are clear on the business value priority.

Once this is done, the next step is to work with the team and agile coach to consider all those other things only they know about: things like dependencies, both technical dependencies and dependencies on other people’s availability and their expectations. But – and here’s the trick – don’t sit back and let dependencies dictate when you do a story. While some technical dependencies may be hard dependencies that truly can’t be moved, you should. challenge all technical dependencies. Often when a team thinks about it for a while, in light of the business value they could be delivering, they realize a hard technical dependency is not as rigid as they first thought. It’s rare to find a non-technical dependency that is a true roadblock. You should push back on all non-technical dependencies. Strive. Try. Endeavor to deliver the highest business value items first – always.  If you decide to do a lower value story over a higher value story because of a dependency (like someone else’s expectations of your “schedule” or a key person’s availability) at least you know you’ve made a sacrifice up front.

Call it out. Make it clear. While it might be the only choice, or maybe even the “right” choice, doing a lower value story earlier is counter to the main goal of Agile. And, if your project is as all-fire important as your sponsors tell you it is, how many of those dependencies do you think they can alleviate? Probably most of them. 

Tip 2: Sanity check your release plan and sell it

After you have the stories laid into sprints, you can look at the release plan in a couple of different ways to see if it all makes sense. Partner with your agile coach on this. The two of you together have the insight needed to do this. Then, the team needs to weigh in. Remember that. The team always needs to weigh in.

On to the sanity checks. First, focus on one sprint at a time. Ask yourself this question about each of the next few sprints:

• Am I asking people to do too many things in this sprint? Are there too many topics to focus on?
• Is there an overload on one or two people with a certain skill set? Or, are we so heavily focused in one area that some people on the team will have “no” work? (Hint: this can be solved for over time by making room for the team to naturally cross-train.)
• Are all the “outside” things lined up, such as people you need to collaborate with, their managers, alignment on your approach or philosophy, etc.

Once you’ve done this and made adjustments at the sprint level, expand your focus again. Look across the whole release plan and ask yourself this, “What are the main storylines happening throughout the sprints and at what points does my customer get value?” Adjust your plan until you think you are delivering the most value in the fastest way possible.

After that, create your elevator speech on the release plan. Get really good at telling the story of what the team is creating and when it produces value. Get good at doing it quickly – remember that this is an elevator speech. Why get good at the elevator speech? Your team needs you to be the heat shield for them. One way to be the heat shield is to deliver this speech to your sponsor(s), other stakeholders, people who have other projects that might derail yours: vendors, venture capitalists, anyone who cares. Sure, some people will want to get deeper and, for them, you can unveil all the detail. Many others just want to be “sold” – they want to know that the team has it under control. This is one tool you can use to demonstrate that control, create alignment, and clear the way for your team to work.

And, remember that great work is never done. You will inspect and adapt the release plan with each new sprint planning session as you see what the team can bring into the sprint and what doesn’t work anymore. You will also adjust the release plan as the world around you changes. Business value priority, for example, will change according to market pressures and external forces. Let this ripple through your release plan as it happens. Just as the sprint plan always reflects reality, so, too, should the release plan.

"Four"warned Is Forearmed

By Mitch Lacey

You are on a team that is both newly formed and new to practicing agile. Your daily Scrum meetings (standups) appear to be going well. You can see the trust building and are looking forward to your team’s first demo. The big day comes, you get in front of the customer and then the floor drops out. Your app starts acting in a way that is definitely not as intended—all because of a hidden blocking issue.

You wonder to yourself, “Didn’t we do everything right? Didn’t we ask all the right questions?” The team dusts itself off and gets ready to start the second sprint. How do you ensure that going forward the team drives out those blocking issues in the daily Scrum?

Add the fourth question.

The Story

My team, we’ll call them Eagle team, had all been individually burned on projects in the past; we were looking forward to working together because we saw Agile as a way of alleviating pains and creating a killer work environment.

On the second day of our first Sprint, we had our first team daily Scrum meeting. Our plan for the Sprint had been solidified in the planning sessions the previous day and we were ready to rock! Unfortunately, it turned out that we were about to get rolled.

We did not have formal training at the time on Scrum or XP, so we weren’t quite sure what we were supposed to do at these standups. One of the team members, Robert, asked, “OK, so now what?”  The project manager on the team, Steve, looked around sheepishly and then began fumbling through Ken Schwaber’s Agile Project Management with Scrum looking for the guidelines at the back of the book (Ken calls them rules; I like guidelines).

After two embarrassing minutes, Steve found what he was looking for: The Three Questions of Scrum. Steve said to the team, “We need to go through this list of questions.” He rattled them off:

• What did you do yesterday?
• What will you do today?
• What blocking issues do you have?

“Who would like to start?” asked Steve. The team jumped right in. Each person answered what they did yesterday, the work they wanted to accomplish today, and stated their blocking issues.

These blocking issues ran the gamut from “waiting to pair program” to things we never would have brought up in the past, such as, “It’s too hot in this little space.”  It was hot, about 80 degrees Fahrenheit. There was a lot of hardware in the little team space, so this was going to be a recurring issue—and it was one Scrum let us do something about. The team was pleased with our first daily Scrum meeting and immediately felt good about ourselves. We were communicating!

The daily Scrum meetings continued to go well as the sprint went on. The team held itself accountable and the blocking issues that were being raised, even the heat issue, were being addressed. Our happy little ship was moving in the right direction, never mind that monster iceberg on the horizon—the iceberg that only one person saw but didn’t say anything about.

The first demo meeting could not come fast enough. The team behaved like kids on Christmas Eve. We had accomplished a lot of work over the first thirty-day sprint and wanted to show it off. We prepared a slide deck, a mandatory element when presenting at this company, listing out the accomplished work, the work that was not accomplished and what it meant for the team to be done.

One of the stakeholders, Thomas, was also the executive sponsor of the agile experiments the team was running. I noticed him throughout the meeting, perhaps because his face lacked the emotion that the other stakeholders exhibited. It was as if he almost knew what was about to happen.

The team was demonstrating the last component when suddenly the system crashed; well, crash may be too strong a word, but it definitely behaved in a way they did not intend. This caught the team and the stakeholders off guard, but not Thomas. He sat there, watching the team flop around like a fish out of water, looking for answers. One of the team members, Marcelo, said to himself under his breath, “I knew this was going to happen.”

The team was astounded!  Steve looked at Marcelo and asked, “What do you mean? How did you know this was going to happen?” Realizing the entire room had heard what he had said, and hearing Steve’s response, Marcelo became quite embarrassed and looked away, not making eye contact or speaking with anyone while the rest of the team fumbled around trying to save the demo.

The stakeholders let the team off the hook and in the end, everyone had a good chuckle. The team was building a mission-critical system to support an online business for millions of subscribers. They were expected to find issues like this, early, and address them. Plus, the team was also experimenting with agile, so the communication breakdown was accepted as an early failure, but one that would not be tolerated by the stakeholders again in the project. Our failure to communicate was as critical to fix as the bug that surfaced in the system—Thomas thought it was the most important thing for the team to address to date, bug be damned!

After the meeting, I grabbed Steve and Thomas to talk about what had happened. The first question out of Thomas’ mouth was not about the system. “What happened with the team?” he asked. This clearly caught Steve off guard. Steve was confused and asked for more clarification.

“You clearly had some blocking issues that were not being addressed throughout your Sprint, why weren’t you resolving them?” Thomas said.

Now Steve was even more confused. The team had been answering the three questions of Scrum. They had raised blocking issues and addressed them. Heck, even the heat issue was resolved after $5,000 of duct work to pump more cold air into the space! Steve was convinced that Thomas didn’t know what he was talking about, and challenged him. “Thomas, I’m not sure you have all the data you need to say that.”  Steve went through the Sprint backlogs with him, showing him the work being done daily. He walked Thomas through our risk and issues log, highlighting the fact that the issues were being resolved.

Steve thought he was making a pretty good argument. Thomas held his ground, “I’m not talking about the issues that are being surfaced by the team; I’m talking about the issues that are not being surfaced by the team. Those are the real issues you need to look for; they are the ones that will cause you to have more demo meetings like you just had.”

Steve and Thomas spent the next two hours analyzing what happened. They discussed the importance of recognizing nonverbal communication and discussed techniques that would help to address it. They discussed the personalities of the team members and most importantly, tied them together. This was the “ah-ha” moment for Steve.

One of the team members, Marcelo, is very introverted. He does not like to make eye contact, often goes out of his way to avoid small talk with people and likes to keep to himself. Yet, here he was working with four other people that he had no history working with, in a team workspace, pair programming no less! He had signed up for this project based on the hope that it would go well, that it would deliver value and that it would stretch his skills. What the team had failed to realize was that it would also stretch his personality and working style habits.

Marcelo knew the team was going to see an issue in the demo, yet he never raised the concern during the Sprint. He was the proof that the team had missed rooting out the real issues that most teams encounter, like communication.

That was when Steve came up with “The Fourth Question.”

The Fourth Question

What is the fourth question in Scrum?  Its simplicity is embarrassing, but it is a valuable tool to ensure that the team is on track—especially for new teams. In the daily Scrum meeting, start with the three questions as you normally would:

• What did I do yesterday?
• What will I do today?
• What blocking issues do I have?

Now add the following:

• What is your confidence, on a scale of one to ten, that the team will accomplish the goal of this Sprint?

That’s it. Why does this work?

In the story above, what Steve and Thomas theorized, and later validated, was that Marcelo was not comfortable with conflict. He was going through the motions in the daily Scrum meeting, but he was not yet vested in the team. The trust among the team was not as well established then as it was as the project progressed.

Another factor why Marcelo was not stating what he truly felt was that other team members were strong extroverts. These people were very comfortable with conflict and, in the beginning, dominated the daily Scrum meetings. This behavior caused introverts (and sometimes the rest of the team) to agree despite their misgivings because the strong personalities would not back down.

In these scenarios, team members do not state the real issues, only surface issues. I have witnessed the implosion of teams because they were not able to root out real team issues. They stayed focused on the software, not on themselves. When they failed, and they all do, they blamed the process, not themselves. The teams that succeed are the ones that are open to change, to experiments, to trying new things. It is these teams that realize they need to improve to succeed, so they remain focused and disciplined.

The fourth question gets past surface issues and carves right down to the core issues—the ones that have long-term (and negative) impacts.

As the Eagle project progressed, and the team bond and trust became stronger, the team found that the fourth question was not needed. Individuals became comfortable with conflict, and those extroverts with strong personalities learned to “tone it down.”

Keys to Success

So, when should you use the fourth question of Scrum? I recommend using it at the beginning of any new project. Even if people know each other, they may not have built the trust required to have the open and honest conversations that ensure project success.  I’ve made it a required element for any team that is either new to itself or agile practices and principles. Eventually, the team will grow to a point where the fourth question is no longer necessary. The team will know when it is no longer needed, so the team should decide if and when it should be dropped.

When using the fourth question, look for the following:

• Nonverbal communication. What is being communicated through body language is often as important as what is being said out loud. Being aware of it and monitoring for it is essential.
• Project issues that are not surfacing. If you are going through your daily Scrum meeting without uncovering many impediments, yet during the Sprint, issues “keep cropping up,” you need to add the fourth question of Scrum. This also applies to stakeholder demonstration meetings.
• People who are not comfortable with conflict. This closely relates to nonverbal communication; however, the ScrumMaster or project facilitator may not be skilled in identifying nonverbal communication. Seek out the advice of others that have worked with the members on the team in past projects to better understand how people work.
• Opportunities to practice continuous learning. Two elements that have helped teams that I have worked on and coached are the Myers-Briggs assessment and workshop and Bolton’s People Styles at Work. Providing the team with the tools needed to stretch themselves personally and to develop their competencies will have a lasting impact on the current project and all future projects.

A Balancing Act

By Andy Brandt

A certain level of discipline is necessary to achieve organized progress. Too much discipline, on the other hand, can hinder both the progress and the quality of the results delivered by the team. This is especially true for creative work such as software development, in part because of the personality traits of people doing it. Software development attracts a certain kind of individual: somebody with above-average intelligence, an above-average ego, a few weird interests and personality quirks, an obsession with tools, and a love for the art and craft of building software. It’s no wonder that managing a team of developers has been jokingly compared to herding cats. The manager constantly has to strike the right balance between discipline and freedom, separating what is crucial and must be monitored closely from what is incidental and can be left up to the team.

Agile processes, which make visible what is most important and truly necessary for orderly progress, can help with achieving this balance. Scrum’s “daily scrum” instills discipline by requiring a fifteen-minute daily meeting where each team member shares what they have completed, what they are working on, and what obstacles they are facing. Other than that constraint, though, Scrum grants the team the freedom to decide how they will work to achieve the goals they committed to during the sprint planning. The tight pressure of a release date being no more than three weeks (the length of one sprint) away is usually enough to ensure people organize their work day in a most productive way. Technical-level agile practices such as XP or TDD are strict about how the code is being built or what it should look like but are flexible about the what and when—decisions of this nature are left to the team and to the individual developers.

This is how we work at Code Sprinters. We maintain a highly disciplined process but allow plenty of freedom, both in choice of tools, office rules, and in adding project-specific guidelines to our universal standards.

Tool Choice

I've seen comments that “lack of unity in tools” is a bad thing; I strongly disagree with that. Diversity in tool choice is a sign of a good, creative team that focuses on what is important rather than trying to appear organized by standardizing the incidental. We don't force our developers to use the same tools. They can use Windows or Linux (I wish we could afford to give everyone a Mac as an option too, but this is not possible yet) -- whatever distribution of Linux they want. They can use a company laptop or their own. They can use an IDE (e.g., Eclipse) or they can use traditional but powerful tools such as VI or Emacs. Why? Because to create quality software, the developer must feel comfortable with the tools he uses. Forcing everybody to use the same standard tools would be as wise as forcing them all to wear the same size shoes.

We do have a minimal set of tools everyone has to use, but all are independent of a particular OS/platform. We all use our Scrum tool to plan, manage tasks and update progress, and register impediments. We require everyone to have Skype running on their laptop to stay in touch with others and clients. Everyone must use company e-mail and calendar, our SVN repositories, project wikis, and so forth. But this is hardly the level of standardization that, regrettably, has been reached at many other companies where everyone has to use the same version of Windows on identical PCs, staring at the same IDE.

Relaxed Atmosphere

In the same way that we don’t mandate tool use, we don't strictly enforce working hours. What we do enforce is presence on the daily scrums -- everyone on a given team has to be there and there are penalties for being late. While being in the office is expected and encouraged, there are no set hours. We have people running in just before the Daily Scrum and people who arrive in the office early in the morning morning. Surprisingly, even without a mandate, whole teams usually sit together in our "war room." It seems that making it both enjoyable and palpably productive to be in the office works much better than enforcing presence.

Universal Standards

Finally, there are certain standards that are applied universally across our organization. These include coding style, test coverage, the way the repository is to be used (what is acceptable as commit and what is not), and the proper procedure for starting a new project. We do not waver on those definitions. However, teams working on a given projects may (and frequently do) add to those existing rules additional standards that for their particular project. A good example is the release procedure, which looks different in each project and ranges from just tagging the release in the repository to working with the client's server(s) to actually putting the new release in production.

Our approach – strictly enforce a few key things; be relaxed on others - has worked extremely well for us. It gives us the discipline we need but allows us the freedom we crave. Following it to the letter may not be practical for every team, but achieving balance should be part of good practice on any agile team.