Links to Article Series and Key Posts

Here’s the starting links for some article series and key posts. Enjoy!

And now to the rest of the blog….

Blazed and Confused

March 27, 2014 by  
Filed under Agile, Scrum

Here is a reprint of my article originally published with Scrum Alliance in March 2014. Enjoy!

Been blazed and confused for so long it’s not true . . .

So, your Agile transformation journey has been underway for a few weeks, a few months, or maybe almost a year. You have blazed a path toward agility. But, much like the Led Zeppelin song (Dazed and Confused– please, you don’t have to be from the ’70s to get the Led out!), there is a huge pause in the middle of the journey, and now you are not really sure if you are going anywhere.

This is the perfect time to do two things:

  1. Celebrate how far you have blazed your trail to agility.
  2. Figure out where and how to keep moving forward on the Agile journey (and certainly how to stay away from falling back into Waterfall).

Celebrating your Agile trailblazing so far is important. Take a few moments to reflect on the effort spent, look back on your accomplishments and the distance you have traveled, and appreciate what your software delivery life looked like only a few short weeks, months, or year ago. It is important to remember the effort it took to start blazing the path toward agility. Organizations are often eager to expend the energy early in the journey because the non-Agile ways of delivering software were so painful. However, do not use this opportunity to say, “We are plenty Agile already.” There are numerous examples of organizations that get comfy with where they are on their Agile journey and feel that they have learned all they can learn. What a shame! And how subtly the fall back to pre-Agile days can happen, without your noticing that you are actually going down the Waterfall again.

It is time to push on your Agile journey! If you are truly going to be an Agile trailblazer, you need to build discontent with the status quo. What does that mean, and do I really want to build a discontented organization? Creating discontent for the status quo means raising the awareness and building a vision of what could be — and of how different, and how much better, that destination is from where you are now. This takes real leadership, not just from the anointed leaders but also from others within the organization. Anyone can recognize that the journey is never finished, that you can blaze a new trail from the place you stand now to an even better destination.

This takes creating a real culture of continuous improvement within your teams. You need to take sprint and release retrospectives seriously and make sure that investment in the smaller and larger improvements is made continuously. So, discontent in the status quo means standing still is unacceptable — and yes, we all want our organizations to feel a lack of contentment with standing still. If you are not sure where to harbor that discontent, get someone outside of your teams (leaders and team members from other teams, external coaches/consultants, Agile conferences, etc.) to help take a fresh look at things. Also, think of all the areas of solution delivery that could be improved upon compared to where you are today:

  • Intent grooming – Business ideas turn into development team member work in hours, not days and weeks, and intent is expressed in a form that fosters development and testing automation (i.e., ATDD/BDD).
  • Architecture – Software architecture is intentional and minimizes systems dependencies to allow design during Agile iterations to emerge effectively.
  • Build, deployment, and release automation – Development team members develop solutions, and continuous integration systems automatically do the rest.
  • Test automation – Unit, service, functional, performance, load, and security testing automation works to the point where feedback on any change to your code base gets run through the entire wringer in minutes or hours, not days or weeks.
  • Environment provisioning automation – Development and test environments are always available and created on demand as needed.
  • Fungible team members – Team members are cross-trained so that developers of one system can be developers of many systems, developers can develop test automation, and testers can develop as well.

So, celebrate your Agile journey so far, and get moving on blazing the next part of your Agile trail. And, most important, enjoy never being finished with your journey toward continuous improvement!

We’re speaking at Scrum Gathering New Orleans 2014!

We are happy to announce that Naeem and Brian will be speaking at the Global Scrum Gathering New Orleans 2014. Our session is called “Hop Onto the Release Orientation Trolley” (in the New Orleans theme) and will be held on Tuesday, May 6th, at 11 AM. This session builds on concepts from our Scrum Alliance article, “The Big Lever” – so take a look!

Hope to see you down in the Big Easy!

Speakers: Brian Barr, Naeem Hussain

Room: Jasperwood

Track: Hop On a Streetcar

Type: Lecture

Level: 1

This session will cover the WHAT, WHY, and HOW of release orientation:

1) What does it mean to be a release-oriented organization? (WHAT)

2) Why should you move to release orientation? (WHY)

3) How do you make the shift to become a release-oriented organization? (HOW)

WHAT (25 minutes): Project oriented organizations focus entirely on getting a related set of intent packaged into a container called a project and seeing that entire container move through from requirements generation to software release. Release-orientated organizations are singularly focused on continuously getting releases out the door that maximize business value delivery without being constrained to only releasing related business intent in the portfolio. To achieve the continuous release of software systems, organizations must apply lean thinking and principles to every aspect of their delivery frameworks and minimize the overhead associated with making releases with high quality.

WHY (10 minutes): Release-orientation gets the entire organization to focus on the most important reason we exist as software developers – maximizing business value delivery through frequent, quality software releases. Moving the organization towards release-orienting thinking provides an invaluable lens for wise organizational decision making.

PROS/CONS Game (35 minutes): Now that the room has a base understanding of the WHAT and WHY of Release Orientation, we will break into groups at each table to play the Pros/Cons Game (see

HOW (15 minutes): The move from project-orientation to release-orientation is both a mindset shift as well as a framework practice change. For too many years, we as software developers, IT shops, and businesses have been successful delivering projects.

Q&A (5 minutes): The session will finish with a brief questions and answers section.


REGISTER NOW for the Global SCRUM GATHERING® New Orleans 2014 - #SGNOLA


Sixth installment – the starting problem series – the worst leadership mistake

As experienced leaders, we expect that our managers and executives trust us as well as give us autonomy in decision-making. Some call this empowerment. The secret for this empowerment begins with trust.

Way too many organizations, attempt to adopt agile methodologies. Many fail. Leaders in these organizations make one critical mistake – they do not have confidence that given the new “freedom”, their team members will do the right thing. At the core, they lack trust. Now, as a manager or leader, there are deliverable that you are accountable for. And if you cannot deliver on these expectations, it is clearly a setback and in many cases with consequences. So how can you as a leader navigate this situation?

Consider these guidance:

1) Grow up – you have hired adults and so, you just have to allow them to be adults. Tap into the core element of responsible adults – have your team and individuals make commitments. They do not need directions at every point. Let them do their job.

2) Shorten feedback cycles – be selfish – ensure that they do not commit to deliver in 18 months, instead, have them break things down delivery to every few weeks. This will provide short-term delivery goals and evidence, and give you runway for building your confidence.

3) Set goals – you are still the leader and you have to set goal. The key is to influence your team to buy into the goal. Don’t impose, influence.

4) Listen  - if your team raises an impediment, acknowledge and work with them to resolve it. Take ownership – be the person who backs them and they will back you. Represent them, but challenge them to keep chugging along.

5) Ignite their passion – trust your team, challenge them to deliver, ignite their passion. Praise them for hitting the short deliveries, congratulate, and appreciate.

To get your team to trust you, you will have to trust them first. Your growth is dependent on their success. Get out of their way, be the coach, provide direction and your constraints. For where you want to go, let them determine the road – trust the team. You will get incredible insights on how to get there fast and cheap.

<<Previous Article

The Starting Problem Series – Fifth installment – Is innovation and reward important in agile transformation?

Inspired at @gwu @uchicago

I recently was a judge at the Annual GWU SEAS R&D showcase where young talented engineers displayed their latest work. Three impressions that I walked away were: 1) the boundless creativity and imagination displayed by students and 2) how much I learned about their projects in that short interaction and 3)  the most important one – the pride each student felt when s/he presented their work.

In one moment, I time traveled to my days in engineering school as a student and then the transformation as a young adult working for large corporations. Once in the corporate world, that receptiveness to new ideas from diverse set of talents was not as much nurtured. Unless of course, you had the good fortune to inherit a manager who really cared or work for a company whose DNA is sequenced for teams and innovations. However, this is fabled manager seems to be the exception rather than the rule.

In my personal journey as a student of agile methodologies and as leader or follower of organizational transformations, one repeated pattern emerged, and that is when organizations transformed some how, people became engaged, new ideas flowed, information was shared and innovation broke out.

Here is what I think are some intrinsic reasons why innovation breaks out in agile organizations:

1) People feel pride in their work because agile organizations recognize teams and individuals continuously delivering (every sprint and release)

2) People build on diverse ideas because agile organizations break down silos and allow humans to interact, to build on each other’s ideas, to grow intellectually, and really experience collective problem solving

3) People influence others to join them to solve complex problems because agile organizations foster leadership by influencing others to join their cause.

4) People feel a sense of accomplishment because agile organizations deliver something their customers actually use

5) People feel they have contributed because agile organizations allow individuals to exhibit their expertise and craftsmanship

As you design your organization for agile transformation, ask the key questions:

1) Are individuals allowed to display their expertise?

2) Are they delivering continuous business value to get the shot of fulfillment?

3) Are team members empowered to make decisions and lead without significant permissions?

4) Are delivery-distracting team member politics minimized (i.e., managers, needing permission, etc.)

5) Does your reward system support both team and individuals?

It is critical that organizations hire the best talent and then create the environment that utilizes the passion and entrepreneurial spirit of these people to allow innovation to break out. We all know innovation is key for business growth today. Let’s ensure that as these young grads join the workforce, their ideas and passions are guided to create great value. Go Boundless Creativity!

<<Previous article | Next article>>

The Starting Problem Series – The Problem with Agile Recipe Books

February 2, 2014 by  
Filed under Agile, AgiLEAD, Starting Problem Series

Ever tried getting a recipe book and recreating your favorite dish made by your favorite chef? You have followed all the instructions, gotten the right ingredients, and channeled your inner Emeril, but the dish still does not come out a 5-star meal. What has this got to do with agile transformation? Read on.

You heard a colleague boast of results they achieved using agile methodologies at her last job, or maybe your boss just asked you to drive agility into your organization. To get the ball rolling, you are now reading a book on agile requirements and doing lots of other research on agile frameworks. You have officially embarked on your agile transformation journey. Let’s assume you are in an organization and at a level in the pecking order that you can influence change. Also, let’s assume that you have convinced your peers to support you in this transformation. Where do you begin? What is the recipe to agile transformation?

Agile transformation is much more than recipe, ingredients and following instructions. The journey is about being open to experiencing the transformation, giving up control and exploring new boundaries of leadership. The prize – an organization so self-organizing and committed to delivery that every associate enjoys coming to work like nowhere else they have been!

You will know if your transformation is heading in the right direction when, for example, a developer makes suggestions about changing your release processes, drives it through your organization and his plans and ambitions are not held back by the “owner” of release management process. This, my friend, will create the joy to be at work. Your organization will rejoice as examples like this become common place and they start realizing this is the sort of work place they want to be..

Here are some ingredients that may be part of your recipe:

1)    Talk to your leaders, listen to their concerns – their leadership is most valuable to make the transformation successful. Engage your leaders with delivery responsibilities and map these responsibilities to the outcomes that are expected. Publicize these outcomes within your organization, support your leaders and hold them accountable for timely progress. Your leaders must deliver real change – not reports or a new reporting mechanisms – rather real change that impacts the way people work.

2)    Cut the red tape – every process that does not add direct value to the customer is waste – you can bet that you have plenty of waste in your system. Create a backlog of this waste, prioritize based on the impact of eliminating the waste, and execute the backlog by putting automation or a leaner process in place. One at a time – do it.

3)    Set money aside to invest in DevOps – free up your developers to focus on one thing – delighting your customers with flawless software. In other words, let them be software craftsmen. Get your developers and testers out of the business of creating manual builds, deploys and manual testing.

4)    Get your best people to build your technical practice. Let your architects solve the biggest technical hurdle – getting your development operations to flow. Ensure that your technical practice delivers continuous feedback to all stakeholders involved.

5)    Bring an über transformation specialist, or “transformation chef” onboard – a dedicated, experienced agile transformation specialist. There is no substitute for this ingredient. The reasons are simple. First, the transformation obstacles this “chef” has experienced do not need to be repeated by your organization – avoid unnecessary pain where possible. Second, the “chef” can help you plan out your agile journey and some near-to-long term waypoints.

While there are many outcomes to be expected, exercise good judgment in picking your “transformation chef”, the recipe and the ingredients. Imagine if your executive team is expecting a gourmet meal from your transformation and you end up serving them a Big Mac! You might find yourself working at the golden arches!

<<Previous Article | Next Article>>

The Starting Problem Series – Realistic Agile Transformation Expectations

Expectations are everything. If you set a goal, communicate it and then meet it, your team is thrilled and so are your stakeholders.

Organizations quite often operate with their collective head in the sand and have self-proclaimed “optimized” internal processes and are therefore not looking for critical feedback to make improvements. Over a period of time, they become dysfunctional. However, since this decay in processes and capabilities is gradual, no one internally feels the pain or the need to change. It’s almost like the frog that is put in cold water and then the pot is set to boil. Alas, it’s too late for the frog to find out how close it is to its end. It usually takes a new leader or a costly error that causes organizations to change their product delivery processes and adopt agile methodologies. Usually, these errors force a change in leadership and the new leadership drives change in the organization.

When an organization gets into the groove of transformation, leadership demands root cause analysis and inevitably, a lot of questioning of current processes and procedures happens. A common problem during this phase is that some people utilize this opportunity to look for “organizational scapegoats” who are believed to be the root causes for these problems, with little or no appreciation for why the process had been put in place. It usually takes a long time for processes to be embedded in an organization and the transformation period leads to some unreasonable expectations for effective process changes to be realized in a very short period of time. All the while, expectations of in-flight projects are to move as fast if not faster than before as soon as the transformation starts.

Agility and transformation can bring out the best or worst of your organization. If your transformation is guided correctly and the focus is on answering the 5 Why’s, you will arrive at the core processes that need to be re-engineered. Surely, there will also be a few laggards in the organization who may not be on board with transformation, and hence may have to depart from the organization. This should not be surprising as not every one in every organization can be assimilated into an agile organization. Agile also amplifies the needs of your organization’s demands – especially from “traditional cost centers” – development, QA, and infrastructure. Suddenly there is need of investment for the right resources and to invest in new tools and infrastructure to promote your organization’s agility. It is key for leaders focus on lean and then automation – focus on getting to short-term results with a long-term success strategy.

As you start your transformation ask a few critical questions for investments:

1)    Do you have the right team members – who can BE agile, not only DO agile?

2)    Have you committed sufficient budget to invest in building key DevOps capabilities that can help in accelerating your organization?

3)    Is your leadership committed to aligning resources and processes to ensure that flow can breakout?

4)    Are your teams willing to be empowered and be held accountable? Is your leadership willing to de-centralize decision-making?

5)    Does your leadership team recognize the value of a transformed organization and are they willing to dedicate top talent for a few months to drive organizational change?

The responses to these questions will give you an indication of what expectations need to be set with your team, leadership and stakeholders whom are all eagerly anticipating your transformation yield results.

As you start your agile transformation journey, ask the difficult questions, be honest about your organizational capabilities and those it lacks. Plan the transformation and communicate the transformation roadmap so that all stakeholders involved can a have realistic expectation of your agile journey. Otherwise, you may find yourself in jumping out from one boiling pot to different, “agile pot” and, again, not realize the heat is turning up. .

<<Previous Article | Next Article>>

The Starting Problem Series – The Agile Resource Allocation Dilemma – Part 2

In the previous post, we outlined the Agile Resource Allocation Dilemma and recognized that this is a pervasive issue and a tough one to solve.

If you need some motivation to start solving for dedicated teams, here are some results that you could expect if you start agile teams without 100% dedicated allocation:

  1. Scheduling ceremonies – stand up, planning, review sessions, etc. become a nightmare due to conflicts in priorities and working on multiple initiatives, resulting in a lack of daily accountability of deliverables.
  2. Instead of teams working together every day and having opportunities to collaborate, they negotiate “how many core hours do we have a day and when?” This leads to uncertainty of delivery capability at the team level and more importantly task switching for resources that, as we know, causes waste in the system.
  3. The product owner and scrum master are often at odds with the functional managers whom still generally have delivery accountability and will often call the prioritization decisions. Given the other critical projects that need to be completed, additional task switching is inevitable.
  4. Sprint commitments mean nothing since team members with partial allocation do not consider the agile team as their “first team” and hence, struggle to establish and to own the team’s sprint goals. This commitment that individuals provide and then strive to meet, evaporates with partial allocation of resources leading to unmet sprint goals.
  5. Even for those team members whom are 100% dedicated to the team, it is often challenging to motivate them to commit to goals when other important team members are committed part-time to the cause and have other priorities. Missing sprint commitments becomes acceptable and a culture of commitment cannot find a foothold in the organization.

If you find yourself in this situation, here are some thoughts to consider:

  1. If you can get 100% allocation at the start of sprint – do it. This is absolutely the best course of action, so ask the “5 Whys” when someone tells you that “partial allocation is the best we can do.” By the time you get to the 5th Why, you will often find that the partial allocation mentality can be overcome.
  2. When you stand up agile teams, ensure that each team member can claim that their team is truly their “first team” – i.e. all work that is prioritized for a team member during transition is allocated via his/her first team. The functional managers need to request capacity from the product owner and scrum master of the agile team. In other words, if there is other critical project work, consider shifting those stories over to the team where the critical team member lives, prioritize it appropriately, and have the team commit to that work along with their other sprint commitments.
  3. Ensure that every person can claim that they are part of an agile team – i.e. they do 60% or more work for this team during transition. In this way, all team members will get familiar with operating within agile practices and they will most likely start demanding that all their work comes through the backlog and team commitments.
  4. Allow your product owner and scrum master to plan your initial sprints with capacity utilization of shared resources between 50% to 70% and gradually transition to 100% over 2 sprints. In this manner, you can treat the “other project work” as ad-hoc requests to be serviced with any remaining capacity.
  5. Determine a transition plan for achieving100% resource allocation, pick a date for getting there, and stick to it. The transition time will ease the pain of moving to the new allocation model and the deadline will provide some urgency to make sure you get there. This is time to be disciplined about the transition – don’t fake it!.

As a leader if you want to drive a “culture of commitment” in your organization, you have to demonstrate this commitment by your actions and allow agile teams to form that can make commitments. This is such a critical element for enabling your organization to create value at a sustainable pace. When you create dedicated teams, you significantly increase the team’s probability of success and hence, the results you expect from agile teams. When you have chosen to transform to an agile organization, begin with making this commitment – the commitment to fully allocated resources in the agile teams. The results will be exceptional!

<<Previous Article | Next Article>>

Passed the Certified Scrum Professional Exam!

January 17, 2014 by  
Filed under Agile, Training

Happy to report that I took the Certified Scrum Profession (CSP) exam this morning and passed with flying colors! My biggest reason for working towards the exam was using it as a forcing function to do a whole lot of reading about a variety of agile subjects. Over the past 8-9 months, I read the following titles and added to my knowledge base using mind mapping software (I love iThoughtsHD on the iPad):

  • Agile Software Development with Scrum – Ken Schwaber
  • Agile Retrospectives: Making Teams Great – Esther Derby
  • Succeeding with Agile: Software Development Using Scrum – Mike Cohn
  • Agile Estimating and Planning – Mike Cohn
  • Test Driven Development: By Example – Kent Beck
  • Agile Product Management with Scrum – Mike Cohn
  • Refactoring: Improving the Design of Existing Code – Martin Fowler
While I have been doing the Agile and Scrum thing for 9+ years now, there’s no substitute for continuous learning. So, thanks to these authors and Scrum Alliance for a great excuse for upping my agile game.

The Starting Problem Series – The Agile Resource Allocation Dilemma – Part 1

Congratulations! You have now convinced your management team to adopt agile. Everyone (or at least most) in your leadership team have extended their support toward this initiative. Everyone believes that this transformation will be excellent for your organization as 1) you are adopting agile 2) claim that your organization is challenging the status quo and 3) you will be able to do product delivery faster.

All transforming organizations and their respective leadership experience a tremendous amount of excitement during this phase. There is a desire to get 100% results and now the leadership team has to commit resources to agile teams to jump-start the transformation. At this “starting point” is when transforming organizations experience the challenges with making commitments.

Typically, prior to adopting agile, a software development and delivery organization would be organized around functional skills – Development, Quality Assurance, Project Management etc. This “tower” or “silo” organization makes sense in the waterfall world to “maximize” effectiveness of the delivery of the artifacts associated with that functional skill. In addition, team members work on multiple projects and tasks that are allocated to the resource by a project manager. This structure and process is very common across most pre-agile organizations.

In the new world, all these resources need to be part of agile teams – self organizing teams that produce 100% of the results based on sprint commitments made by its team members. The management team expects nothing less than this. However, the challenge facing leaders is that they often do not fully adopt the “dedicated team member” principle of agile and continue to allocate part time resources to the intended agile team. The most likely cause of continuing to split allocations of team members is that they still have a critical role or knowledge required to deliver other critical projects.

In the next posting, we will outline the impact of ignoring the dedicated team principle and some ideas for helping to transition to fully dedicated teams.

Next Article>>

AgileTrailblazers sponsoring Agile DC 2013

September 22, 2013 by  
Filed under Agile, Continuous Business Value Delivery, Events

AgileTrailblazers is proud to be one of the sponsors of Agile DC 2013. This conference is being held on Tuesday, October 8th from 7 AM – 5 PM at the Kellogg Conference Hotel at Gallaudet University in Washington, DC.

If you are attending, come by and meet Brian and Naeem at the morning coffee (on us!). We would love to meet you and talk with you about how AgileTrailblazers can help your organization achieve outstanding results with Continuous Business Value Delivery®.

If you haven’t signed up yet, go to the Agile DC site and make sure to be there for what promises to be a great event!

See you there!