A Meetup with Philippa Fewell!

If you missed Philippa Fewell’s Meet Up where she speaks about how Agile 2 came about – you are in luck, we have it here! Philippa shares with us how she and a group of 14 other Agilists reflected together over a period of 8 months to create a new set of values and principles called Agile 2. We invite you to listen, learn and enjoy her lively discussion!

A look at Agile 2’s values and why we need both sides of the coin to create value.

While the values of the original Agile Manifesto have helped shift the way software is developed today, it is very much left to the interpretation of the individual applying them as to how it should be done.  This interpretation can often be dogmatic to focus solely on the left, sometimes at the total exclusion of those on the right, even though it clearly states  “That is, while there is value in the items on the right, we value the items on the left more”.

Agile 2 consists of six values and 43 principles. It comprises a deep and nuanced set of ideas, and all of its ideas are supported by the thoughts that led to them. In this article I am going to provide a view into Agile 2’s six values and why we chose the word ‘and’ instead of ‘over’.  Agile 2 seeks a balance of both the left and the right, both are needed, and both are useful. Also, Agile 2 seeks to speak to a broader range of activities beyond only software, including product development in general, and in fact any collaborative human endeavor.

The Values of Agile 2

Let’s take a look at them one by one.

1. Thoughtfulness and Prescription.

Frameworks are good and useful.  They often give us a place to start and help us to solidify an approach.  But they should not be followed blindly without considering your own context – where are you and what can and can’t you do in the context of your organization.  Many variables are at play to construct the perfect environment for a framework to succeed, including organizational structure, culture, compliance regulation, and leadership support to name a few.  A practice that is best for one organization may not be the best or have a chance of succeeding in another.  That is not to say that you can’t move towards an ideal, but it very often isn’t the place you can start.

This contextual variability is why thoughtfulness is essential when applying a framework, or any practice or methodology. However, there are cases when one should start with a well-defined practice and follow it precisely. For example, if one is replacing a component of a complex machine, such as a blade on a jet engine, following procedure is often essential for ensuring that it is done right. Lives and safety might depend on following the procedure rather than improvising.

Still, judgment is sometimes required. Surgeons often have procedures for specific types of operations, but they need to be able to improvise, using their own judgment, when things do not proceed as expected; their experience and judgment are key, and the patient’s life might depend on it.

There is a place for prescription; and there is a place for thoughtfulness. Knowing the right balance is a matter of context.

2.  Outcomes and Outputs

In the course of product development, outputs are the things that get produced by the development teams. These are usually design artifacts: digital files that define the product and its fabrication (hardware) or deployment (software).

Outputs are important – they help us measure our progress using metrics such as the team’s throughput, number of defects, quality of the software etc.  These are mainly what you might call activity-based measures.  But ultimately, we are building products or creating a service for our customers using Agile to achieve some business outcome.  Sure, the customer will care about the quality, no one wants a product that is not stable, and the organization may not achieve its revenue target or market share if the product is not released on time.  But the product also needs to be what the customer wants and will use. It must be the right product and someone or some group needs to be accountable for directing that vision to achieve the desired outcome, which is the true measure of success for the organization.

So, outputs matter: they are essential elements of any process; but they are not the end goal. The end goal is the outcome.

3. Individuals and Teams

We often hear there is no ‘I’ in ‘Team’ and much of what is written about Agile is written regarding the practices of the team.  Teams are necessary to accomplish much of what we do, as no one person has the knowledge or capacity.  But Agile often advocates for the team’s preference over the preference of the individual, be it with team norms, communication style, and even the team environment.  This can be to the detriment of the individual, which can then cascade into the detriment of the team reaching its goals.

Balance is needed so as not to stifle creativity or alienate team members simply because they do not think, learn, or process information in the same way.  It is necessary for teams to have norms but sometimes allowing someone to operate outside of the majority’s norm is needed too to accomplish the team’s goal.

4. Business Understanding and Technical Understanding

We often hear that business is the driver, and that technology is the enabler, that the business is responsible for the “what” and that IT is responsible for the “how”.  This thinking has led to many structures where development teams are led by product managers who have a great understanding of their domain but very little understanding of how it will be implemented and vice versa.  But knowledge of both is necessary to make optimal decisions.

Technical decisions have financial and future business impact, and business decisions have financial and future architectural impact.  Not every person can have a deep understanding of both, but they should not entirely shift the accountability of understanding to someone else.  Instead, they should seek to understand as much as possible and collaborate closely.

5.  Individual Empowerment and Good Leadership

Self-organizing teams is one of the first things people often talk about when discussing Agile.   Two of the principles behind the original Agile Manifesto state:

“Build projects around motivated individuals.  Give them the environment and support they need and trust them to get the job done” and

“The best architectures, requirements, and designs emerge from self-organizing teams.”

These are often translated into “leave the teams alone and don’t tell them what to do”.  Yet not all teams are ready for that level of autonomy and authority.

Empowering teams, or individuals for that matter, is a great motivator.  It can bring about better outcomes, and it can help to build future leaders within the organization.  But to empower people without some level of supportive leadership and assessment is to set them adrift.  Borrowing from a talk by former Captain David Marquet, teams need to have clarity of purpose to set direction and competency and the capability and skills necessary to get the job done .  Good leadership will assess the level of oversight and direction that the team needs and help them navigate while teaching them how to make good decisions on their own. 

6. Adaptability and Planning

One of the original values of the Agile Manifesto contains the phrase “…responding to change over following a plan”.  I do not think anyone would disagree that planning can be useful, or that if there were a significant change that would cause the goal to not be achieved then adapting the plan would not be a good idea.  The point is that both the act of planning and the ability to adapt that plan are valuable.

The planning in and of itself helps us to think through the variables that would have us choose one option, course of action, timeline, etc. over another.  It helps us think through the constraints we must work under and the risks we face if we come up against them.  Keeping these things in mind with respect to what is occurring while executing the plan gives us useful information, we can use to adapt the plan for a better outcome.

Conclusion

Both sides of the coin, heads and tails, are necessary to create value.  Agile 2 believes that both sets of values are necessary to achieve agility.  Balance is needed and consideration for the context of your situation when applying practices that might favor one over the other.  I do not believe the Agile Manifesto meant to infer only one side of the coin either, and that the word ‘over’ has led to misinterpretation and rigidity on how to apply it.  I could be wrong in my view and understanding also.  Therefore Agile 2 has provided interpretation and insight as to how the values were derived, so as not to be misinterpreted.  There is a lot of thought and experience behind them from the original authors.  However, we expect Agile 2 to evolve and develop with input from the community.  We hope that you take some time to review Agile 2 and add to the ideas and content that comprise it.

Agile 2 is here!

I was fortunate to be included in a group of exceptional Agile leaders and practitioners, led by Clifford Berg, to retrospect on Agile and improve upon what it has become over the last 20 years.  Each of us began by citing issues and problems we have encountered over the years, drawing on our unique experiences.  Not all of us experienced the same issues, but it was eye opening to discover what others came up with because of the diversity of the group both in practice and expertise.

We then discussed why we felt the problems occurred and what could be done to change them.  This led us to revisiting the values and principles of the Agile Manifesto and many of the frameworks we use today.  While I am vested in many of these, having become certified in them myself and trained others on them as well, I have seen where lack of clarity or difference of interpretation, as well as too much emphasis placed on prescription, leads to less than successful outcomes.

It is this clarity and thoughtfulness that Agile 2 seeks to deliver.  It is a set of values and principles based on common problems that we believe will resonate with you, the Agile practitioner.  My colleagues and I are proud of Agile 2 and the potential impact we believe it can have on the current state of Agile.  Have we gotten it all right?  Undoubtedly there is room for debate. Have we missed some valuable principles?  Perhaps. And that is why we want Agile 2 to be open to ideas from the community, and there will be an Agile 2 version 1.1.  We respect and welcome your input and ideas.  We want Agile 2 to be constantly improving on what it is today so that it stays relevant.  There will be Agile 2 community forums, and to begin that, there is a LinkedIn group. A book is on the way. The Agile 2 website is at https://agile2.net. Check it out!

We’ve all heard something about Documentation in Agile. I know I’ve heard some pretty extreme comments like “there is no documentation”. Well I’m here to set the record straight.

Let’s start by taking a look at the Agile Manifesto:

Agile Manifesto

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

As you can see it isn’t that there is no documentation, but rather we favor the delivery of “working software over comprehensive documentation”. So what does that mean, and why did I emphasize the word comprehensive?

If you are fairly new to working on software projects, you may not remember the days of huge requirements documents like I do. Projects started out with a group of analysts working together to create a requirements package over the course of several months. We would engage with the customer, run workshops, and watch what users did. We’d end up with one or more three-ring-binders full of documents. There would be statements like “the system must….” and “the system should….” We would give each line item a priority (High, Medium, and Low typically). Then we would create as-is process flows, to-be process flows, context diagrams, data flow diagrams, object models, and state transition diagrams to name a few. Each set of requirements were presented to and signed-off by the main stakeholders; and that may have been the last our stakeholders heard from the team until the software was ready for user testing. At the end of the project, the documents would end up on a shelf somewhere eventually being shipped off to long term storage, never to be seen again.

The Manifesto reminds us that no matter how much documentation we create, if we don’t produce working software, then we aren’t creating value for our stakeholders. It also reminds us to evaluate the documentation we do decide to create in order to ensure it is of value for the project.

The perceived lack of documentation in Agile environments isn’t just because of the manifesto, it is because everything we do is slightly different in Agile compared to a waterfall approach. We no longer create a load of requirements and toss them over the wall hoping the team will understand them enough to create a design document and code. Instead, we work together throughout each sprint to ensure we are creating value together by delivering working software together where everyone has complete understanding of user stories, and everyone is on the same page regarding the design as it emerges sprint by sprint. When specific documentation like Release Notes, or User Guides are required a user story is an acceptable way to track these documentation needs.

As the team discusses user stories in grooming sessions, the goal is to have each story fully understood by the team. The team may suggest other stories, or identify other items they need. The Product Owner and Scrum Master can work together to obtain documentation that is needed by the team to better understand the story. The team adds notes to the story to track decisions and comments that are made  keeping story documentation with the story. So what else might the team need? When working with a user interface, the team will likely need a wireframe or mock-up of the user interface. The team may also want an object model or database diagram. I’ve even known one developer that requested a State Diagram. Unfortunately, there is no single correct answer. The team or Product Owner, may need to engage with other teams (System, Database, or DevOps) to get the desired documentation ready for the team. For a great article on best practices in Lean/Agile documentation check out this article http://www.agilemodeling.com/essays/agileDocumentationBestPractices.htm

The three main artifacts in Scrum are the Product Backlog, User Stories, and Test Results. The Product Owner holds the key to understanding stakeholder needs. Should other documentation be required from a stakeholder or compliance perspective, a story in the backlog is a great way to address this need. Also as development occurs, the team needs to ensure that system decisions and their code are sufficiently documented so those supporting ,or enhancing the system in the future will be able to do so adequately. Consider including something in the Definition of Done (DoD) to ensure stories meet these non-functional needs.

Yes, documentation does exist when following an Agile Framework. However, we don’t create a document for the sake of saying we’ve done it. Make a conscious decision of what will be created, and what the intended use is. This way, you won’t have a library of out of date, never to be viewed again documentation.

Welcome to the final part of my 12 Principles series where we’ll cover the final 4 Agile Principles. (In case you missed it, here’s a link to Part 1 and Part 2). If you utilize all three parts together, you will have a great resource for working with your teams’ Agile growth.

9. Continuous attention to technical excellence and good design enhances agility.  
We may be working in short sprints, but this is not an excuse to let technical excellence slip. Potentially deliverable means the code is tested and passes.

Technical debt is dealt with on a regular basis, and not left until the very end of the project.

This isn’t one and done, so support your teams to be the best they can be. Allocate approximately 20% of each sprint to “technical excellence” https://msdn.microsoft.com/en-us/library/hh350860(v=vs.100).aspx. Some basic things you should be doing are planning for Test Driven Development (TDD), pairing and refactoring. Developers create simple designs, and look for constant improvement through regular feedback.

One final thought, Technical Excellence is about more than developer’s code. It is also about the organization becoming more Agile. Think about working with all members of the organization to improve their skills by cross pollinating, training, and mentoring.

10. Simplicity–the art of maximizing the amount of work not done–is essential.
 The phrase to remember is not to “gold-plate” your features. One best practice here is to follow TDD. By developing to the story and its acceptance criteria until the test passes, and no more.

Some developers may feel they could do more, but what if what they create won’t be used? Then we have wasted time, and a potentially untested item. It’s great to have ideas, so write a story and pass it to the Product Owner for prioritization in the backlog. Remember it’s easier to create complicated solutions, harder to create simple solutions… but simple solutions last longer, increasing quality and decreasing total cost of ownership.

11. The best architectures, requirements, and designs emerge from self-organizing teams.
Change can be difficult, and moving from a waterfall environment to an Agile environment is no exception. In order for team members to identify the best design during Sprint Planning, they must be knowledgeable about the environment and system they are creating. This means we can’t treat them like mushrooms (keeping them in the dark, and feeding them “fertilizer”).

If your organization is working with complex systems, ensure the architectural runway is in place. Expect some ramp-up time for team members to become familiar with the environment. Ensure that there are resources assigned from the “systems” team to support each scrum team. Create domain models, physical models, etc. as needed to ensure sufficient information is available to the team. Then allow sufficient time for the team to discuss and build on their designs during Sprint Planning.

12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Welcome to the Retrospective! Agile is an empirical process. Based on the results, we adapt and improve. When I hear that teams are struggling with retrospectives, I suggest they rethink how they think about this ceremony. It isn’t a gripe session. It is an honest introspection of our performance.

Following this principle means we need to take a look at how we are doing, and commit to experiment to create small improvements. Each and every sprint allows us to try something out, and to look at the results at the end. If the results are positive, great. We can decide to run with the change. If the result isn’t positive, we can choose a different approach for the next sprint. There are great resources out there to keep Retrospectives from becoming dull and boring. If you are struggling, take a look at the book, Agile Retrospectives: Making Good Teams Great, by Esther Derby and Diana Larsen.

It is easy for an organization to be “Scrum-but”. The risk in staying “Scrum-but” is not truly getting all the benefits of being Agile. Read all three parts of this blog and evaluate how your organization is doing. I invite you to add your comments and experiences, as we share in the Agile Community any ideas for continuous improvement!

Over the course of this three part blog, I will cover all of the 12 Agile Principles. In this first installment I implore you to stay tuned for all 12, and get to know how principles can impact your team. I believe following these principles is the core of being “Agile”.  It is a topic I am always excited to discuss. How does your group follow the 12 Principles? Is there room for improvement?

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. 
Let’s face it, if we aren’t delivering something of value, what are we doing?

Everyone on the team must understand the value of what they are delivering. As a team, we become “one” focused on our delivery. The value we provide binds us together, and gives us purpose.

Product Owners can provide the team with a Vision to help guide the team to value delivery. Each sprint delivery supports the vision.

We aren’t all lucky enough to work on feature teams delivering software. If you fall in this category, just replace the word “software” with what you do deliver.

Find your value, and deliver small pieces like building blocks.

2. Welcome changing requirements, even late in development. Agile processes harness change for customer’s competitive advantage. 
While this principle seems to invite disastrous changing of scope at any time, this is not the intent. We do not interrupt sprints once they are started, unless it is a dire emergency. There are ways to stop a sprint, which is a topic on its own. What this principle asks us to do, is keep our backlog up-to-date.

If a new feature is requested, it can easily be added to the backlog. If a feature in the backlog is considered to be out-of-date, it can be removed or updated.

As development progress, and more of the backlog is completed, everyone is learning and discovering together. This principle allows us to change, reminding us that the backlog is fluid.

Organizations need to adapt their policies to embrace these changes, or they miss out on a fundamental benefit of being Agile.

Teams should not feel mad, angry or bad because requirements have changed. I often see negative reactions to change, when just the opposite should happen. Through the teams’ continuous delivery, we learn and therefore we adapt.

I like to tell leadership, through your Product Owner we enable the team to build the highest value features at any time. Don’t get locked into years of work in the backlog. Stay engaged, work with Product Owner, keep the backlog alive. Remember the motto “just enough, just in time”, as it will reduce waste by not documenting requirements too far out in the future, that could end-up being changed, or cut altogether.

3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter time scale. 
You’ve decided to follow Agile. You have a backlog, and a team ready to work. Now you just have to get everyone focused on frequent delivery. Organizations like Netflix deliver continuously (see http://venturebeat.com/2014/03/10/continuous-delivery/). However, the rest of us may be still trying to adapt to delivering at the end of a 2-week sprint.

The reason for short time scales is important to understand. Short time scales reduce risk and waste. We test smaller chunks, we get feedback sooner, and overall can react to change easily when we are working in small increments. A short sprint cycle provides plenty of practice, and opportunities for skill and process improvements.

The team needs small stories. Without stories small enough to be built and tested during the sprint, the team will not be able to fit work into shorter time scales. How small? Half a day to two days of effort. Do you shudder at the thought? Developers don’t always like this concept at first, but it is important to try smaller pieces of work. The benefit of small stories outweigh the fact that developers may have to touch code more than once.

Many Agile organizations aim for two week sprints. Some successfully, but new Agile organization may allow teams to work on just a couple of stories that take the entire two weeks; when complete, these stories may be handed over to a QA team. If you are falling into the latter category, there is still improvements to be done to truly benefit from Agile.

In the Scaled Agile Framework, we are introduced to the phrase “Develop on Cadence, and Release on Demand” http://scaledagileframework.com/develop-on-cadence-release-on-demand/. Supporting the notion that the teams’ developed work may sit until the organization is ready for the release, although it is considered “delivered” by the team. Delivery by the team, means the work passed test and is done. Completed work is ready for Sprint Review. The work is demonstrated and feedback is gathered.

4. Business people and developers must work together daily throughout the project.
Oh how I long to click my heels together, and be transported wherever I want. As an Agile organization, you are lucky if everyone is collocated. It is a desire many of us share. The reality is Agile has moved beyond start-ups and web-dev groups. Agile is embraced by organizations large and small; located centrally as well as all over the world.

Using good communication tools can help us feel like we work together, even when we aren’t collocated. The idea of working together daily, allows everyone involved to participate in the Daily Scrum; it allows us to have easy access to each other. No longer are requirements written and “thrown over the wall” to be developed. Developers can share their screens with us, ask questions, get feedback, and quickly resolve issues when Product Owners and business users are readily available. Don’t wait until the Sprint Review to touch base with your team. You will find you have another way to reduce risk and waste.

Use Team Agreements or Team Norms to identify practices for working together. Collocate teams whenever possible. Invite business users to Sprint Reviews. Include times when Product Owners will be available to everyone, as well as when developers can work uninterrupted.

Let me know your comments, and stay tuned for Part-2 where I’ll will discuss the next four Principles.

Last month I had the opportunity to attend my first ever Coaches Retreat. The retreat was made up of about 80 participants. Preparation for the retreat started months in advance, even for us participants. First we were requested to send in an introduction poster. Second, we were asked to suggest topics for the retreats. As I had never been to a retreat like this before, I didn’t exactly know what to expect. So I thought I’d share my experience of the event.

One of the first things we did after the retreat got going was to form teams around topics. There were plenty to choose from, after all the customers (us attendees) had sent them in. We “self-organized” in teams around topics we were passionate about. I became part of a team organized around the topic of Virtual Teams. Next we set off to plan for three 180 minute sprints. Our team was awesome. We picked a team name; stormed a little, formed a little… We created a vision, a backlog, and committed to sprint 1. Of course we did all the ceremonies for each sprint. Each team’s sprint review was in front of the entire group which provided an opportunity for feedback from customers!

Three days of working with peers from near and far led to each team providing a “product” related to their selected topic in 180 minutes. Wow, what an experience! What a result!

My experience of the retreat was not only a learning experience, but a growing experience. I experienced true team self-organization, and boy was it cool. Within my team, I learned that utilizing Scrum Values (Focus, Courage, Openness, Commitment, and Respect) are as important as the Principles and Manifesto. As our team went through storming to norming, we demonstrated these values. We talked about the work ahead of us, and how we were feeling. Yes, feeling! Our volunteer Scrum Master wasn’t sure she was in the right role; I wasn’t sure I was with the right team. I felt that our team more than any other practiced what we preach as ScrumMasters, Coaches and Trainers. I credit each one of us with following Scrum Values to get through storming quickly. In seeing everything the other teams delivered I gained a set of tools I can utilize anytime. I grew in my sense of belonging to the Agile community, and pushed through my fear and lack of control by exhibiting Scrum Values, and being engaged with my team. The retreat was an opportunity for me to continue a journey of learning and growing, all while making new friends.

Here’s to Team Dysfunction!

As an Agile enthusiast, trainer and coach I’m pretty passionate about being Agile regardless of the specific framework being followed. In fact, my passion lies in the culture of being Agile, rather than a dogmatic adherence to a framework.

Following a Framework

A dogmatic approach to a framework may work well if you are a “.com”, start-up, or other application development shop. But, for those of us working with large corporations a dogmatic approach feels impossible. Here are a few of the reasons why:

• Team members are not co-located
• Teams are not developing software
• Team members are not fungible
• Teams cannot deliver anything fully functional at the end of a sprint (1 – 4 weeks)
• Teams rely heavily on other teams to deliver components, and struggle with dependencies
• Organizations have a legacy structure that doesn’t support being Agile
• Organizations want the teams to be Agile, but they don’t want to change anything else

I fully support adopting a framework, so don’t get me wrong. Organizations should try to adopt as much as possible of their chosen framework, and specifically note exceptions acknowledging deviations from a given framework. However, before the organization gets concerned about the framework they are trying to follow, I ask them to look at the Agile Manifesto and Twelve Principles. How much cultural change is the organization willing or able to accept in order to adopt a framework? As true agility requires both, a change to the new framework and a change in culture.

Cultural Change
When the “gurus” got together in Colorado, they not only defined the Scrum Framework, they created the Agile Manifesto, and Twelve Principles. These two items identify the Culture of Agile. To truly be Agile, organizations must work on the cultural change required regardless of the framework.

From the Manifesto:
Does your organization really put Individuals and Interactions over Processes and Tools?

Carte blanche rules for processes and tools don’t always work for everyone within the organization. Some tailoring must be done to truly be effective. Marketing teams may not need to use the same story writing and management tools as Software Teams.

Do they favor Working Software (Value Delivery) or Comprehensive Documentation?

Note: For non-development teams, I prefer to consider what “value” the team is delivering as working software does not apply.

This is not an excuse for skipping documentation all together.

Does your environment allow for true Customer Collaboration over Contract Negotiation?

Or do you have a hard time trying to figure out who is the recipient of the value you are delivering? A culture of “us versus them” may keep workers away from collaboration

Does the organization Respond to Change over Following a Plan?

Or are we all so worried about scope creep, we have a rigorous change policy? Or has the pendulum swung the other way, and you’re experiencing the “Chicken Little -sky is falling” scenario all the time?

Acknowledging the Agile Manifesto and how an organization may adopt their culture to it, is one of the first steps to agility.

Twelve Principles
To be honest, I find the majority of teams I work with have no understanding of the 12 Principles of Agile. How can that be? Does leadership really believe a framework will work without other changes? Yes, it is hard. Yes, someone will always be unhappy. Welcome to the real world.  If you fail at adopting Agile, and you haven’t tried to change culturally, is it really Agile that doesn’t work? Are teams working to be Agile, while the rest or the organization continues with business as usual?

Think of the simple scale from “Somewhat Agree to Somewhat Disagree”, and for each of the Principles score your organization.

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. (or just value delivery)

This allows our customers to see steady and ongoing progress towards are end goal.

2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

Changes of scope may have an impact, but we need to quit complaining about change.

3. Deliver working software (value) frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Reduce risk, increase collaboration, break work down into small pieces, and get feedback after each delivery.

4. Business people and developers must work together daily throughout the project.

If the team doing the work has no access to the recipients of the value, are you playing the “telephone game” with requirements and feedback?

5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

Agile teams are self-organizing, self-managed, and empowered to do what it takes to deliver quality value at regular intervals. If you’ve truly hired good people who want to do a good job, why micromanage them? Empower your folks, and see what happens. With any luck teams will learn to pick up the stick, and run with it.

6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Skip multiple emails, and meet face-to-face even if it is over the internet!

7. Working software (quality value) is the primary measure of progress.

If you’re not creating software, deliver small pieces that act as building blocks towards completing your value delivery.

8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

A little extra time here and there is okay. However if working 50 – 60 hours is the norm, it’s hardly sustainable.

9. Continuous attention to technical excellence and good design enhances agility.

Going faster doesn’t cut it if quality drops. The focus should always be on delivering quality.

10. Simplicity – the art of maximizing the amount of work not done – is essential.

Do you remember the 80/20 rule? We have a phrase “no gold plating”, so focus on what really matters to the 80%.

11. The best architectures, requirements, and designs emerge from self-organizing teams.

Learning new practices, and engaging regularly to ensure the foundation is sound enables teams to take advantage of emerging technology and practices.

12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Without continuous improvement, being Agile slips further and further away from reality.

Summary

Cultural change is key within organizations in order to really support the Agile Manifesto and its Twelve Principles.  Where does your organizations culture fall when using the Manifesto’s scales, and the Twelve Principles? Work to move the pendulum a little at a time as needed. The origins of Agile lie not in black and white answers but in collaborating to do what is best in our drive to deliver value. Your customers will be happy, and you’ll retain employees and keep them and shareholders happy.

One of the basic Agile tenets that most people agree on – whether or not you’re an Agile enthusiast or supporter – is the value of early and continuous customer feedback. This early and often feedback is invaluable in helping software development projects quickly adapt to unexpected changes in customer demands and priorities, while concurrently minimizing risk and reducing ‘waste’ over the lifetime of a project.

Sprint Demo
In the Agile world, we traditionally view this customer feedback in the form of a formal product demonstration (i.e. sprint demo) which would occur during the closeout of a Sprint/Iteration. In short, the “team” – those building the software – presents features and functionality they’ve built in the current sprint to the “customer” – those who will be users or sellers of the product. Even though issues may be uncovered and discussed – usually resulting in action items for the following sprint – the ideal end result is both the team and the customer leaving the demo session (and in theory, closing the sprint) with a significant level of confidence in the current state and progress of the project. Sprint demos are subsequently repeated as an established norm over the project’s duration.

This simple, yet valuable Agile concept of working product demos can be expanded and applied effectively to other areas of software development projects:

• Why not take advantage of the proven benefits of product demos and actually apply them internally – within the actual development team – before the customer is even involved?
• Let’s also incorporate product demos more often – why wait two weeks (or sometimes even a month, depending on sprint duration)? We can add value to a software development project daily, if needed, without even involving the customer.

Expand the Benefit of Demos
One of the common practices where I have seen first-hand the effectiveness of product demos involves daily deployment of code into a testing or “QA” environment. Here’s the scenario:

• Testing uncovers five (5) “non-complex” defects (i.e. defects which were easily identified in testing – usually GUI-type defects including typos, navigation or flow issues, table alignments, etc.) which are submitted into a bug-tracking tool. Depending on the bug-tracking tool employed by the team, this process is sometimes quite tedious.
• Defects 1-5 are addressed by the development team and declared fixed (or “ready to test”) and these fixes are included in the latest deployment into a QA environment for retesting.
• Defects 1-5 are retested. Defects #1 and #2 are confirmed fixed and closed.
• But there is a problem – it’s discovered EARLY in retesting that Defects #3 and #4 are not actually fixed and additionally, the “fixes” have now resulted in two additional defects – #6 and #7. For purposes of explanation, these two additional defects were also easily identified early in the retesting process.
• At this point, Defects 3-4 need to be resubmitted, with new Defects – #6 and #7 – also added to the tracking tool.

Where are we at this point? In summary, all of this time and effort has essentially resulted in closing out one net defect, and we’ve essentially lost a day’s worth of work. Not to mention, developers are wasting time fixing and re-fixing bugs (and in many cases, becoming increasingly frustrated) and not contributing to the team’s true velocity. Simultaneously, testers are wasting time retesting and tracking easily identifiable defects, therefore increasing risk by minimizing the time they have to test more complex code and scenarios.

So there is our conundrum. In a nutshell, we’re wasting time and team members are unhappy. Check back for a follow-up post next week, which will provide a simple yet effective solution to this unfortunately all-too-common issue in many of today’s software development practices.

In a previous blog, “The Reality of T.E.A.M”, I talked about Agile teams being dedicated, or part of a ‘permanent’ team that focuses on a single solution and remains together over time.  Another big factor of an Agile team is that they are cross-functional in nature.

What is a Cross Functional Team?    
When the topic of cross-functional teams comes up, there seems to be varying opinions that come out.  What does it mean when I refer to teams being cross-functional?  Does everyone on the team have to be able to do every job?  Do all team members have to know every detail of everything that goes on inside the team?  Does the team have to ensure that they can complete their solution?  Let’s look at what cross-functional means for Agile teams that I work with.

If you want to define it, you will most likely find that it means something like “a group of people with different functional specialties or multidisciplinary skills, responsible for carrying out all phases of a program or project from start to finish.”[1]  If you stick with this definition, you may find that you do not have to have a team where everyone on the team knows how to do every job on a team, but more that it is meant to keep members focused more on their role in moving the product forward than on their title.

Now that you’re on a Cross Functional Team
When the members of a team hear they are to be cross-functional, I’ve seen them get a little uneasy thinking they have to become something they may not want to be or learn to do things they don’t want to do.  I call this their ‘mini identity crisis’ because these team members are so centered around their title defining what they are supposed to do, they lose sight of what it means to be a team.

Team members will hopefully come to understand that becoming part of a cross-functional team means they will be focusing more on their role as a team member than on what their title is on their HR file.  Being a cross-functional team member is about ensuring you chip in whenever necessary and do as much as you can to ensure the solution is complete, and as good and valuable as it can be.

It’s not necessarily important that all team members know how to do everything, but it is important they work together, embracing common Agile principles from the Agile Manifesto and Principles, as well as principles that are found in Agile methods, such as “’Collective Code Ownership’ in Extreme Programming, which ensures the entire team owns the code and ‘Self-Organization’ in Scrum, where the team organizes themselves to get the job done.

Where does an Agile Coach fit in?
When coaching cross functional teams, I try to support and help them understand they won’t be losing their identity, but they are going to become part of a larger solution.  I emphasize that they’re not ‘against each other’, or ‘apart from each other’, but ‘for each other’.  I’ve found it’s important for team members to communicate and collaborate so they feel like part of a team instead of a pool of resources thrown together and asked to feel and behave like a team.

For all you sports fans—A Sports Analogy
Cross-functional teams remind me of football teams.  In football, there are multiple positions, both on the offense and on the defense.  While each member of a football team is most likely drafted onto the team to play a specific position, such as protecting the quarterback, the skills they possess for that position may also translate to other positions on the team.  For example, the player that protects the quarterback can use those same skills to get around the protection of the other team’s quarterback and sack him.  Just like a football team has players who are able to move to different positions in order to win the game, Agile teams use the same idea to produce the best possible solution!

Agencies around the government are beginning to see more and more of their employees teleworking and going to modified work weeks.  There are a number of employees that work enough so that they can modify their schedules to be off every other Friday or Monday, or even every Friday or Monday.  Due to a number of factors, many employees are also teleworking, or working from home.  Sound like you or someone you know?

What does this have to do with Agile?

I hear very often that one of the most talked about, and even controversial, things about an Agile transformation is the idea that teams must all be in the same room in order to satisfy the 6^th principle of the Agile Manifesto “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”

If we take this principle into account, then we find that the telework and modified schedules turn this upside down and cause some confusion and concern on whether or not an agency can actually transition.  I have had a number of federal employees, especially leadership; ask if they can really transition to an Agile culture.  The actuality is “yes” – an agency in this situation, can most certainly transition to an Agile environment!

The biggest question for any agency is not “can we?”, but “how do we?”.  The agency needs to start with the understanding that the 6^th principle says that face-to-face is “the most efficient and effective…” way to communicate; it does NOT say that it is the only way to communicate.  It is so very important to encourage face-to-face communication for those that are in the office on a daily basis, but not so important that they relinquish the teleworking or modified schedules.

The key is to have the agency give the teams as much encouragement and support as they can to help create an atmosphere that fosters communication and collaboration in many different ways.  The agency will need to enable team members to communicate through means that may not have been ‘the usual’ in the agency.  Many government agencies have never had to put a lot of effort into ‘unusual’ modes of communication and collaboration because either the employees have been in the office all the time and/or the employees have worked fairly independently.  The more independently employees work, the less they need ways to communicate and collaborate outside of the ‘usual’ means of phone and email.

Agencies that need to step out of the ‘normal modes’ of communication are most likely very skittish of doing so for a multitude of reasons.  Some reasons I have been told that agencies may be skeptical is the level of security that needs to be maintained in the agency; most agencies will admit their security levels are much higher than those of private industry.  Because of the level of security that needs to be supported, many obvious communication mechanisms are overlooked or pushed aside without fully investigating the overall options.

However, in today’s technological age, there are many options that are available.  Any agency that is looking to transition to a more collaborative environment, one in which Agile can flourish, needs to look beyond names and find what works.  They should start by understanding the needs of the teams and work with the teams to find solutions, such as Office365, webcams, bridgelines, etc.

The one thing that agencies should never assume is that they cannot transition to an Agile environment simply due to these modified schedules or teleworking situations.  It all comes down to support and encouragement of teams made of people that are not all sitting in the same location…something that many agencies have not had to deal with before now!

Have you been in this situation?  Do you know some that are?  What do you, or they, think can be done to be more collaborative?