Being Agile When The Business Isn’t – Transparency

In the last two posts, ‘Being Agile When The Business Isn’t – Requirements‘, and ‘Being Agile When The Business Isn’t – Team‘, I talked about how to be more Agile in an environment where the business is strictly Waterfall. I’d like to continue this theme with some ideas and practices to make the teams more ‘transparent’.

Inspect, Adapt, & Transparency

Most will recognize Inspect, Adapt, & Transparency as the three pillars of Scrum but they’re ideas that even the most Waterfall of businesses can use and take advantage of. These three pillars are the core to continuous improvement, building what customers need to solve their problems, and helping bring the greatest valued work to the forefront. I’ll focus on transparency as I believe once you have transparency, inspection and adaptation will follow naturally.

Perhaps the big difference between Agile Vs traditional project management is how these three items are acted upon. When I was doing big Waterfall projects our alleged transparency came from the project’s communication plan. This communication plan defined the reports the project team was responsible for generating. At or near the end of the project, we wrote project closure reports which often included lessons learned. While writing the closure report, we were being formally transparent but only after everything was done. The real problem with the closure report was the timeliness of it. Because this is traditionally done at the end of the project, nothing learned here can help the just completed project. We also suffered from fading memories. We remembered the specific events but often needed to speculate and debate over the causes. Interestingly, we also seemed to forget these lessons for the next project or determine the next project is different enough so the lessons weren’t considered applicable. I’m not suggesting nothing was learned but any learnings carried forward tended to be the exception.

The result is some learning is done but the changes haven’t been trialed or proven to be effective in solving whatever the problem was. To improve requires openness and transparency so you can inspect what has happened and adapt to new and better ways throughout the project not just at the end. To maximize the value of improving, the project team needs to be continuously inspecting outcomes and results including any new ways of doing things. Building in transparency from the start will help.


Transparency is arguably the first step for improvement. Nothing will help a business improve better than seeing undeniable evidence that some work practices, processes, and communications are less than optimal or just plain bad. In the Waterfall environment, the project plan includes what practices and processes the teams will use and the order they’ll use them. Most project plans also have a communication section where and how the various project statuses and metrics are reported. However, it’s only an illusion that transparency exists by executing a communications plan. The reason is, communication plans dictate specific content and intervals, usually within categorizes like any of the following:

  • Current project status
  • Current risk assessment
  • Resourcing status
  • Requirements management status
  • Stakeholder management status
  • Change management status

This doesn’t provide any insights or linkages to bigger or widespread problems. There’s also the problem that the reporting is done by the project manager. This can lead to information being filtered and potentially skewed due to conflict of interest. Project managers are generally held accountable for the project plan which means they’re accountable for perceived progress or the perceived lack  of progress. And finally, after a while, the project manager is most often simple ticking the box on his or her reporting requirements.

Daily standup & transparency

Scrum Trainer Charles Bradley wrote in his article, “The Tao of Scrum – Transparency“, “the best transparency leads to the best collaboration loops”. To maximize the value of collaborative feedback loops requires transparency and to me, transparency implies anyone can quickly gauge what’s happening in a project with a minimum of effort. Although you might be stuck with an old-fashioned communication plan, there’s an easy ceremony you can implement with your Waterfall team that gives extra clarity to what’s happening on the project: a daily standup. Each day the team talks about how their plans for the previous 24 hours went and what their plans are for the next 24 hours. It also provides an opportunity for others with their own unique perspectives to make observations and comment.

In my Waterfall past, as the project was approaching the final stages of test, we had all the project managers, line managers, and the program office people sit together daily to talk about specific tasks the teams were doing and when we thought they’d be done. Although this worked quite well for the management team, the nuance of individual planning was lost. Had there been a team standup, the confidence or uncertainty was more likely to come through. As it was, what was reported to management was an interpretation of plans and status.

In a Waterfall environment, the full project team might be large since the team is built from specialist who usually don’t take on tasks outside their specialty. This can mean the daily standup is large if everyone goes so careful monitoring is essential. The daily standup must remain valuable and true planning must occur otherwise there’s no point to it. In Agile, one valuable component of the daily standup is the collaborative nature of getting the most important work done first. In Waterfall, the project manager and product manager might need to be a little flexible in their detailed project plans to allow the collaborative nature of the implementation team to emerge. Better still is for the project plan be aligned with getting functionality done in order of importance rather than based on components and skills of the team.

Plans & transparency

Another aspect of transparency will be the visibility of the plans. If the project is using MS Project or Jira for Agile teams, it is a huge mistake to think this by itself constitutes transparency. Both these tools track progress when properly maintained but in both cases, people often don’t take the extra steps necessary to open a file or log on to Jira or even learn how to use the tool. The real problem isn’t progress wasn’t tracked, it is, but the real problem is the difficulty of getting to this tracking data and properly interpreting it. These tools have their advantages but ease of use is not always one of them. It’s not that these managers and program office people are lazy but rather their time’s at a premium. Visualizing the project and sprint status on a wall is easy. Bits of sticky paper with notes, in columns is easy. I have used a big wall as a Gantt chart or User Story board to great success. It really doesn’t matter if you’re doing Waterfall or Agile, the advantages of this high visibility is the same: huge.

If your team and stakeholders are global then it’s a wise idea to set up a camera on the planning board. I had used a camera while we did standups to allow global stakeholders to see & hear what was going on. I had a second camera on our ‘story board’ 24/7. This was intended to add more transparency and to give our global stakeholders a bigger slice of the picture, allowing for more feedback and collaboration.

Transparency is a conscious effort

Agile isn’t immune to poor transparency and communications. As Scrum Master, I’ve been cornered by the product owner/manager and asked what the ‘real’ state of progress was in the sprint. Two things needed to happen: the product owner needed to attend the daily standup and the team (with some advice from the Scrum Master) needed to better present state sprint progress. In Waterfall, the project manager has their hands full too. While Agile implies the implementation team is involved and responsible for managing expectations and communicating value completed, Waterfall usually relies on the project manager to do these. It’s up to the project manager to move beyond the project plan and establish a collaborative atmosphere where visibility and transparency become natural within the project team.

Transparency can be scary as it will expose people, their work practices, and their outcomes to all. It’s not the natural state for developers who learned their craft in a Waterfall environment. The first time I had transformed a Waterfall team into a Scrum team, one of the team members told me that they were completely stressed out by the high visibility of their work. In his case, a technical decision had proved wrong in a most open sort of way. In the past, management would probably not know that a technical glitch had happened but Agile made it visible. In hindsight, the team member realized the focus was to identify and correct a technical decision quickly and not to allocate blame or ridicule, (he was unconvinced of this in the first days). Transparency became a tool to do better and improve but not without some pain on the journey. Making previously hidden work habits visible will be stressful for some but this can be countered by avoiding the culture of blame and ridicule.


By using transparency as an aid to see what’s working well and what can be improved, the opportunities for improvement are more likely to be seen. Transparency has two key accomplices: daily standups and the wall project planner. Both these can be used in Waterfall environments without too much effort beyond simply doing it. Having the implementation team being transparent and talking directly to their plans each day is a key element of Inspection & Adaptation. This daily transparency reduces the risk of going off on a tangent as illustrated in the earlier story about an unsuccessful technical decision.

Transparency also extends beyond traditional tracking tools. Although these tools help track and document progress, it requires both effort and training to use these to their full potential. Training all stakeholders and customers with these tools is hard and may be impractical. Using a simple system of sticky notes and a big wall can convey the same information in a visual way that transcends most communication roadblocks. If there’s no wall, then use a big whiteboard. No whiteboard, then use the windows. You can even put a camera in front to broadcast the planning board across the internet if necessary.

Being Agile When The Business Isn’t – Team

In the last post, I talked about how to be more Agile in your customer interaction and requirements gathering when the business is strictly Waterfall. I’d like to continue along the theme where business isn’t as Agile in its execution of projects as agilely proper and how that business deals with the ‘team’ concept.

When I worked in the defense industry, teams were defined around specific functionality. I was a project manager around torpedoes, someone else was missiles, another navigation, and so on. We worked in a loose ‘feature team’ configuration. When you looked a little deeper into our team structure you’d quickly find we were actually grouped specialists, working independently from one another. One or two people would specialize in torpedo interfaces, another person would be pre-launch display, another post-launch display. Specialization was the core of our development efforts and it worked well because we also had many layers of both project and line management to oversee everything going on. If anyone even vaguely looked like they were off track, there were several people monitoring who could set them straight. The team was not allowed to deviate from the implementation plan, deviate from the customer approved designs, or innovate on their own. Control was absolute and the projects tended to be successful, you really can’t lose on a cost-plus contract. Our company, like many companies, talked fluently about teams and teamwork.


Teamwork is a value that almost every company claims. In Agile, there are several principles promoting the idea that the team is central. The principles include people other than the development team as part of the ‘Agile team’. These principles are:

  • Business people and developers must work together daily throughout the project.
  • Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  • The most efficient and effective method of conveying information to and within a development Team is face-to-face conversation.
  • Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  • The best architectures, requirements, and designs emerge from self-organizing Teams.

The best way forward to building the idea of team in product development is through early and constant engagement of the developers, product manager, business stakeholders, and customers. We humans have a tendency to claim credit as individuals for successes and attribute blame to others for failures. In the traditional project management model, the project manager is the person most likely to be hung out to dry if the project misses the project’s cost, schedule, and scope requirements. In the Agile model, we try to allocated responsibility to the larger team. Agile encourages participation of the larger team to accomplish great things. It’s important that the larger team understand and feel responsible toward achieving these great outcomes. This feeling of responsibility can occur with or without a project manager. The best Waterfall projects I was on made expectations clear to everyone from the developers all the way up through to the program office. Managers and workers alike knew what was expected of them.

In either a Waterfall or Agile environment, building a strong team is equally possible. The key to get people feeling responsible for project outcomes is providing them with clear definitions of expected individual actions and outcomes. Creating a great team starts with getting those outside the development team, stakeholders, managers, program office, sales, marketing, and others, aligned with the team.

Stakeholders as team members

In Agile, we might start with a ‘Who Do’ table like the one shown below. In traditional project planning there is often a Stakeholder Management Plan or Stakeholder Involvement Matrix. Building the plan or ‘Who Do’ table will be much more meaningful if done with all the stakeholders and development teams together. Getting a verbal acknowledgement from stakeholders and development team members alike will greatly increase the likelihood of people following through and honoring their individual and team commitments.

Getting all your stakeholders and team members together in one room might be difficult if your project is huge. However, the rewards will be better understanding and commitments to the project by those who can influence the successful outcomes. If there are too many people then the Scrum Master or Agile Project Manager can get the larger group to break out into smaller working groups, each with a defined purpose. For example one group might represent the architectural steering committee and define what the company requires, what stakeholders need as far as information goes, and what the development team (or project team) needs from the architectural steering committee. The facilitator gets more than just a list of items but gets everyone to commit to delivering what they said they’d deliver.

The outcomes and ‘Who Do’ lists are drawn up for the entire project and placed on a wall in a very prominent location. This must be visible to all and not buried in a document in some obscure location.

For the Scrum Master or Agile Project Manager, the main obstacle will be the reluctance of the business to commit the time necessary for this meeting, whether part of an Inception Workshop or stand alone. The key argument for such a meeting is to remove project risk and increase chances of project success by clearly identifying actions and individual responsibilities throughout the organization.

Development team

In Agile, the Agile development team is usually defined as a team that not only cares about the work they collectively do but they care about the growth and well-being of each other. In a Command & Control environment, survival often rests with the individual watching out for themselves. My experiences in Command & Control environments was your individual performance was what mattered and the ‘team’ was secondary. Stopping to help someone was not uncommon but the usual action was to inform management that a person wasn’t up to the task. It became a management problem, not a team problem. The difference between being in a ‘group’ and being a member of a ‘team’ is the ability to sacrifice your time to help or guide others.

If the business is rooted in a Command & Control hierarchy, being told what to do is the norm. To achieve aspects of an Agile team mentality requires the group to not only adopt the project goals but for the group to lay down objectives and goals for themselves. One way to form a team from the group is by defining boundaries with the team and management. Within these boundaries, the team is self-reliant and self-managing. The team can define their own behavior using a Team Charter declaration. A Team Charter is a common artifact in Waterfall and Command & Control environments and can be used to identify many of the Agile behaviors in a familiar form. I’ve found that the act of developing the charter with the team is more important than the resulting document. The charter is placed prominently on the team’s Sprint Board.

Management concerns will rest along the lines of giving up some control. These managers are being held responsible by those above so it is a leap of faith to grant the team any autonomy. For the Scrum Master or Agile Project Manager, it will be important to ensure that there exists some checks and balances so the managers can feel comfortable. These concerns will most likely initially focus on ‘output’ (not outcomes) of the individual sprints. The Scrum Master can help the team report their sprint progress in terms managers need to hear. In the past, I had focused on reporting user stories estimates which began very high as a reflection of the team’s uncertainty. Over time, the size of stories fell which was directly related to the team’s efforts in backlog grooming. This demonstrated real progress, the team better understanding the work before them, something that was both visible and valuable to the business.

Example Agile Team Charter

The act of creating the team charter is more valuable than the resulting document in my opinion. The team debates each item and may spend a little time on the exact wording but in the end they agreed to the concepts and behavioral traits. Give it a try.

  1. The Team will decompose tasks so they can be done in less than one day – based on knowledge at hand.
  2. The Team will display a Sprint Backlog burndown chart prominently to track progress.
  3. The team will constantly review the content of the Sprint Backlog to ensure it is complete (no missing tasks) and that all tasks planned and being undertaken are necessary for the successful completion of the Goals.
  4. The team will alert the Product Owner immediately should it become apparent a committed User Story or Goal cannot be achieved.
  5. Every Team member has a responsibility to speak up if they feel a Team member is working on a task that is of a lower priority to other tasks not yet started. Every Team member is responsible for the progress of the team, not just of their own progress
  6. The Team will fix any bug they’ve introduced during the Sprint unless the Product Owner approves not fixing the bug.
  7. The Team will create automated tests (unit, integration, functional, acceptance) even if the result is reduced functionality during the Sprint.
  8. To move a task from “to do” to “in progress”, the task is broken down to no more than can be done in the remaining time before the next Daily Scrum meeting – based on knowledge at hand.
  9. When a task moves from “to do” to “in progress”, the Team member commits to working that task to completion.
  10. The Team will integrate working code often, no less frequently than every 24 hours.
  11. The Team will not tolerate broken builds. If the daily build is broken the team will refocus to fix the build immediately.
  12. The Team will not check-in new code if the daily build is broken
  13. Before a coding task moves to “to verify”, the following items must have occurred (part of the Team’s definition of “Done” for a functional task):
    1. Code and Unit/Integration Tests are peer reviewed using pair code walk-through technique
    2. Code unit/integration testing have been automated and added to the daily build
    3. Developer build made and integration testing completed successfully
    4. The assessment of impact (for the change or new feature) is documented on the Jira form with any recommended regression tests identified.
  14. To Move Task From “to verify” to “completed” requires (part of the Team’s definition of “Done” for a functional task)::
    1. Daily build with changes has no errors (if errors, source backed out and task returns to “in progress”)
    2. Product Owner has been informed that a new daily build is available and what new/modified functionality is completed
    3. Automatic unit/integration tests run during the daily build have 0 errors and warnings
    4. If applicable, acceptance tests run successfully for completed User Story (or portions run successfully for partially completed User Story)
    5. Jira used for code delivery has passed verification and identified regression tests have been run.
    6. All new defects are entered as Jiras. Principle development is complete with issues treated as rework via Jira.
    7. Team member who developed code and plus one or more team members have run the Jira verification and recommended regression tests on the daily build
  15. The Team will work at a sustainable pace; a pace which can be maintained for 12 months.
  16. Every Team Member will actively seek out and eliminate waste in Software Development

A Development Team’s Agile Journey

If you’re working in a Scrum software house, ideal development teams are self-organizing, empowered to make decisions, and engaged as a full partner in the business as it relates to the product. But what are the essential first steps that will begin the development team’s Agile journey to get there?

We’ll take a quick look here at some steps I think are necessary for that journey to occur:

  • The business gives the team space to make decisions by defining the boundaries
  • The business empowers the team to make decisions within these boundaries
  • The team actively takes on the responsibility for all work by building skills within the team
  • The Scrum Master, team lead, and managers help the development team by practicing behaviors they wish the development team to adopt

The challenge

When a Scrum team first forms, it’s built from the remnants of the previous methodology, usually Waterfall. This is fine because the team starts off knowing something about the product and code. Still, a freshly hired team might have the advantage of not having preconceived ideas about their roles, responsibilities, and teammates. This sets up a change issue that needs to be overcome during the development team’s transformation to Agile: reset the thinking team members have about roles, limitations, and responsibilities. If possible, the Scrum Master tries to reset the development team so they start their Agile journey knowing their specialties and interests but without any other preconceived ideas of roles or responsibilities. Resetting and changing team member views of roles will be challenging but not impossible. Maybe.

When I was introducing Scrum to a team, I had a problem with getting everyone on the team to contribute to the testing effort during their very first ever sprint. The developers had always done code & unit test but they were never asked to do acceptance and system level testing, that is, until Scrum showed up. The situation arose when the single professional tester on the team became overwhelmed with writing and running tests. The developers were sympathetic but their only advice was for the company to hire more testers. The team lacked imagination and work experiences to even entertain solving the problem themselves.

Instead of listing out options from simple to hard, they fell back on their past experiences and decided that the way to solve the problem, the way they’ve seen it done in the past, was to throw bodies at it. For the developers, the simplest solution was to make it someone else’s problem, In this case, the managers needed to hire more talent. This had been a learned reaction by the developers over the years doing Waterfall and you couldn’t fault them too much.

There’s a high likelihood that while the developers were under the Waterfall umbrella, their work was specialized. It’s also likely the project manager’s task assignments in the project plan was based on these specialties. For example, a back-end developer would probably not be asked to do front-end display work and no developers would be asked to write the system level tests when there was a perfectly good team of QA testers available. The idea of development team members knowing one thing super well and to continue perfecting that one thing, is pounded into them from the first day.

With the Scrum development team, we still celebrate each team members’ special skills, the skills that made them valuable to the company in the first place. These skills will continue to be valuable when adopting an Agile mindset. So there’s really two things we want to change in the development team:

  1. Get the team to feel that development and delivery problems are theirs to solve even when it requires work outside your strengths and
  2. Develop stronger team thinking skills for problem resolution.

And the way to change how development thinks starts with management.

Management support of Scrum means tough love

Getting the team to acknowledge that our test situation was their problem to solve took a bit of time but they eventually did accept it. That there was a problem was obvious and this was not in dispute. We needed to get the development team to see that the old way of dealing with this kind of problem wasn’t an option. The journey’s first step was begun by senior management.

I was lucky that the General Managers of Development and Product were supportive of Agile and Scrum. Both these managers told the developers that there was no chance to hire and train new testers for the team given the delivery date. This was brilliant in that they didn’t simply say “solve it yourself” but gave the developers a real constraint that required the team to find an alternative.

The Scrum Master and Team Lead needed to lead change by example

The next thing was the development team needed a slight nudge in the right direction. This was done by myself as Scrum Master and by the team lead. Together we both began doing some testing tasks. We provided by example, a way forward for the team. This setup everything for the next step.

Get the team to be involved with a passive approach: get volunteers

At the next daily stand-up, we both gave our accomplishments from the previous day but asked for help from the remaining team members. As with any good group of people, when they’re asked for their help they provided it. Our team sat down after the daily stand-up and took on all the outstanding testing tasks. The reality was that testing didn’t take too much time, a day or so, and the value of finding problems during the sprint meant we could provide a higher quality product at the end of the sprint.

Behavior change starts with how we think

Positive team thinking usually starts with the confidence that the development team can solve their own problems. This means that the team must be empowered to solve a problem and feel confident that they have the necessary tools and skills to solve it. Building these two attributes won’t happen overnight. Making a strong deliberate effort to achieve both makes good business sense, especially if you think about the reduction of waste and a newfound enlightenment of the team.

One goal of Scrum is to harness the power of the team to make quick and better decisions. One foundation for this is the team’s confidence in itself to make decisions without relying on outsiders too much. This means the team working together to make choices on architecture, design, and implementation based on their collective product knowledge and within boundaries set by management. Fear usually exists and swirls around things we don’t know about. We are reluctant to make decisions while in the dark about a subject (most of us anyway). To build this decision-making capacity we start with building team knowledge so we can leverage the cumulative power of the team.

Team empowerment

Before the team can become self-organizing, they must first be and feel empowered.

We’ve all worked in offices where the business declared teams are empowered but this lofty claim does not jive with reality. Should you expect the company to say, “do what you want, when you want to do it”? No, of course not. What the Scrum Master or Agile Project Manager need to do is get the business to establish boundaries from which the development team can operate. Give the development team some space to operate independently in.

I’ve recently worked closely with a manager to help him move from the company’s Command & Control model to following a Servant Leadership model. I used two tools, a camera for filming his interactions with the team and listening to the conversations he had. Using these two tools, I was able to show him how he made most of the decisions, big and small, for the team. He hadn’t realized how often he was making decisions, he believed the team made the majority of the decisions. But the camera doesn’t lie. To change this around and give the team decision-making power, he followed the practice of pushing decisions to those who had the necessary information to make it. In this case, the development team. He followed the “intent based leadership” style of David Marquet, author of “Turn the Ship Around!: A True Story of Turning Followers into Leaders“. When a team member discussed options or choices with him, he recognized that they were actually asking him for direction. He found that he could answer most questions with, “what do you think?” This got the desired effect of team members now talking among themselves to discover the best way forward.

Establish boundaries for the team

In management’s role of supporting Scrum, they pass to the Scrum team business rules and establish boundaries for teams to work within. Part of empowering the team includes whatever limits the business feels comfortable with. In general, a Scrum team is given a free hand to build a product that solves the business or customer problem. However, there might be business or technical restraints, (non-functional requirements), placed on the team. For example, the Scrum team can’t arbitrarily decide to stop supporting a certain web browser because they don’t like it. It’s possible the company will go crazy with rules and restrictions but this should be balanced by having the team and managers drawing up the boundaries together. This is how our Servant Leader above created boundaries with his team to great effect.

Team strengths & weaknesses

It is sometimes thought that Agile development team members strive to become generalist but this is a false goal. It is not about everyone on the team learning how to do everyone else’s job but it is about everyone on the team feeling equally responsible for getting all the work required done, even if it isn’t your specialty. A good team acknowledges their individual strengths and plays to their strengths. While playing to the team’s strengths, a weakness might be uncovered. For example, if only one person on the team can code in Ruby, the potential weakness in the team is when Ruby work is required but the one person who knows it is sick or otherwise not available. In the past, the absence of one person could lead management to acquire another Ruby programmer from a lower priority project or, more likely, Ruby work would be postponed until the right person is back.

The Scrum Master can use a portion of the team’s retrospective to bring to light any shortcoming of skills or control noticed during the sprint. The team can together develop the appropriate actions to make this weakness go away or at least mitigate it.

Reduce waste by reducing hand-offs: Building T-Skills to make work-flow more fluid

When the development team worked within the hierarchy of a Waterfall environment, their job was to get tasks done as quick as possible. Once the unit tests passed, they would release the code to the test team. However, if you were to apply Value Stream Mapping techniques, you’d almost certainly discover that there are many zero or non-value adding periods within the Waterfall lifecycle. This would be most evident in the hand-offs between specialized teams. In an Agile team, these hand-offs can still occur: when the teams’ work moves from one specialist to another, when decision points are reached and the team cannot independently make the decision, or when one person has a particular skill and the team waits for that person’s availability. The solution is for the team to improve their ‘T-Skills‘. This will probably ruffle some people because their own sense of self-worth might be centered on a unique skill they alone have.  Here’s where the Scrum Master works their magic.

Building ‘T-Skills‘ means we don’t slight or forget the person’s key skill (the vertical line of the T). The goal is to create the capacity of having a second opinion when necessary and to still move work forward without the specialist. We want the team to have enough skills to step in and do the work if needed, even if it takes 3 times longer (the horizontal line of the T). The point is that work does not stop; it might slow down but it doesn’t stop. To build T-Skills will require a skills matrix.

The team goes through all the skills within the team and answers yes or no the these three questions for each skill:

  1. I am an expert
  2. I want to learn more
  3. I’m not interested

If you use a skills matrix similar to the example above, there is probably a need to address any skill that does have two or more people rated at 3 or above. When I’ve done this in the past as Scrum Master, I would arrange for any external training or setup an internal training session for those who wanted to learn more. The skills matrix is the beginning of an action plan to build ‘T-Skills’.

Here’s one example: With sufficient T-Skills, when code and unit test are done, the same team member begins higher level testing. They do this not as a specialist but as someone who can contribute. Once the test specialist is available, the testing will proceed faster. This practice removed the hand-off and made the transition from code to test fluid and easy.


These ideas don’t guarantee success because once started, these behavioral changes must persist forever or until the next best thing comes along to replace Agile. It is far too easy to fall back on old habits, ask anyone who has quit smoking for the fifth time. The best thing to do is create metrics and monitor these for continued improvement or a relapse.

Empowerment and team boundaries can also erode over time. Once the team and management have defined boundaries, everyone should sit down once a month or once a quarter to re-work these. In the normal course of experience and time, team boundaries should be seen expanding. This indicates a growing trust of the team and the team’s growing understanding of the business. If the boundaries are shrinking then there’s probably a [big?] problem.