Tag Archives: Agile PMO

Product Development versus Project Development

Agile has been most widely used in “product” development environments and less widely used in “project” development environments.  The difference between product development versus project development is not widely recognized.  Of course, this is not a totally universal, black-and-white distinction; but, in general:

  • Products are less deterministic and the business model is usually a little more open-ended.  For example, a company might say that we want to develop a product to satisfy “X” market need (where that market need may only be generally defined and might need to be validated) and we’re going to invest $X to fund a team for ongoing development to support that product development initiative.

For many products, it’s an effort that simply goes on-and-on without end to provide ongoing support and enhancements for the life of the product.  Products are generally somewhat speculative and might require a significant amount of innovation particularly if it is something that has never been done before.  For that reason, a product development effort is very well-suited to an Agile development process.

The business model behind a product development effort is typically based on a projected return on investment (ROI) that the decision to invest $X in the ongoing development effort will provide an acceptable return from the profitability that the product will generate over a period of time.

The decision process associated with a  product development effort is generally focused on prioritizing what features should be added to the product to provide the highest level of customer satisfaction and profitability.  That decision process is ideally suited to an agile development process.

  • Projects are typically more deterministic and less speculative.  Very few development teams are given a “blank check” to do some kind of project without having some expectations of what the project will accomplish, what it’s going to cost, and what the schedule will be.

The business model behind projects is also typically very different.  A company typically has a given amount of funding to invest in projects and some kind of project portfolio management approach is generally needed to determine the appropriate mix of projects that will provide the greatest overall benefit.  In order to make that decision, something must be known about the expected results, costs, and schedules of the projects in that portfolio and there is an ongoing need to monitor the performance of those projects to see if they really are going in the right direction to provide the return that was expected.

The process associated with managing a “project” is also typically different…the general nature of the features the “project” will provide would generally be much more well-defined prior to the start of the project, there would typically be some expectations about what the cost and schedule of the project would be, and it probably wouldn’t be completely open-ended to add features as a “product” might be.   These are key reasons why it is more difficult to apply an Agile development model to projects than it is to products.

Applying Agile principles and practices in a “project” development environment rather than a “product” development environment can be a bit more challenging but it definitely can be done.  Agile works best where there are no constraints on costs and schedules and the primary goal is to add features to maximize customer satisfaction (product model).  When you introduce constraints on costs and schedules (project model), this is the area where it is many times appropriate to use some kind of hybrid managed agile approach to meet the competing demands of a highly flexible and adaptive development approach and the predictability of meeting cost and schedule constraints that is often demanded in a project environment.

The Hybrid Agile Development Approach I’ve described in one of my other posts is an example of how this can be done.  It involves wrapping a “shell” around an Agile development process that can be as thick or thin as you want it to be to provide a sufficient level of planning and predictability to meet the needs of the business environment while retaining a lot of flexibility and adaptivity within the development process.

 

Emotional Intelligence in Agile

The role of emotional intelligence in Agile is important to understand. HelpGuide.org defines “emotional intelligence as follows:

“Emotional intelligence (EQ) is the ability to identify, use, understand, and manage emotions in positive ways to relieve stress, communicate effectively, empathize with others, overcome challenges, and defuse conflict. Emotional intelligence impacts many different aspects of your daily life, such as the way you behave and the way you interact with others.”

“If you have high emotional intelligence you are able to recognize your own emotional state and the emotional states of others, and engage with people in a way that draws them to you. You can use this understanding of emotions to relate better to other people, form healthier relationships, achieve greater success at work, and lead a more fulfilling life.”

Why is that so important in an Agile environment? Because Agile relies so heavily on teamwork and open, honest, and transparent communication both within the team and with other stakeholders outside of the team.

HelpGuide.org goes on to define four key attributes associated with “emotional intelligence”:

  • Self-awareness – You recognize your own emotions and how they affect your thoughts and behavior, know your strengths and weaknesses, and have self-confidence.
  • Self-management – You’re able to control impulsive feelings and behaviors, manage your emotions in healthy ways, take initiative, follow through on commitments, and adapt to changing circumstances.
  • Social awareness – You can understand the emotions, needs, and concerns of other people, pick up on emotional cues, feel comfortable socially, and recognize the power dynamics in a group or organization.
  • Relationship management – You know how to develop and maintain good relationships, communicate clearly, inspire and influence others, work well in a team, and manage conflict

Source: www.helpguide.org/mental/eq5_raising_emotional_intelligence.htm

The easiest way to see how this impacts the performance of Agile teams is to observe the behavior of someone who has a low level of emotional intelligence. Here is an example: on an Agile team I’ve worked with, there was one particular individual who was very bright and intelligent but had a very strong and dominating personality and what I would consider a low level of emotional intelligence:

  • He liked to be in control of everything and be seen as the “hero” who is leading the entire effort – there was a saying on the team that if it’s not XX’s idea, it sucks
  • He was opinionated and confrontational, didn’t value other people’s perspective, and attacked other people openly in emails
  • He had such a vested interest in his own ideas and proving himself “right” that he lost objectivity and wasn’t able to see different sides of a decision

How does that impact the effectiveness of an Agile team?

  • It can stifle the contribution of others on the team – it’s well known that more minds can work better than one and the performance of a team is maximized when everyone on the team is fully engaged and actively contributing to decisions and the work of the team.
  • It can lead to poor decisions because decisions may be biased in favor of one person’s point of view and may not objectively consider all aspects of the problem

Here’s some excellent additional reading on this subject:

http://www.helpguide.org/mental/eq5_raising_emotional_intelligence.htm

How do you acquire “emotional intelligence”? I believe that the first and most important step is self-awareness – you have to be somewhat introspective and be able to look at yourself openly and honestly and also learn to be comfortable being open and transparent with others. That doesn’t come naturally to all people and requires a certain amount of self-confidence to develop. Many people have a “shell” that they operate within and that “shell” can be either thick or thin. There’s a concept that I learned a long time ago called the “Johari Window” that is still valid today. The Johari Window breaks up people’s self awareness into four quadrants:

  1. Open/Free Area – Personality attributes and characteristics that are known to yourself and to others
  2. Blind Area – Personality attributes and characteristics that are known to others but not by yourself
  3. Hidden Area – Personality attributes and characteristics that are known by yourself but not by others
  4. Unknown Area – Personality attributes and characteristics that you are not fully aware of and others are also not aware of.

Source: http://en.wikipedia.org/wiki/Johari_window

Alan Chapman has created a very nice diagram that shows the relationship of these four quadrants:

Johari Window Model

Source: http://www.businessballs.com/johariwindowmodeldiagram.pdf

People who have a high level of self-awareness and who are also open and transparent in their behavior with others have a relatively large quadrant one (Open/Free Area) and the other quadrants are relatively small. Of course, the objective of increasing your self-awareness, openness, and transparency is to increase the size of quadrant one (Open/Free Area) relative to the size of the “Blind” and “Hidden” quadrants. Another objective is to more fully develop your true potential through self-discovery of skills, attributes, and characteristics in the “Unknown” area that neither you or others you interact with are fully aware of.

Years ago, I can remember many companies made self-awareness training a key part of their management development curriculum for new managers. The principle behind that was that you couldn’t be very effective as a manager if you had a hidden personal agenda and you weren’t open and transparent in your relationships with other people. Your employees will recognize the external veneer that you put on, see right through it, and lose respect for you.

Unfortunately, over the years, many companies have cut back on that kind of training. It was perceived as too “touchy-feely” and when times got tough, it was one of the first things that got cut because it was not seen to have a direct contribution to company profitability. The relationship to company profitability may be indirect, but I think it is just as essential today for managers and even more important for people participating in Agile teams.

There are some exercises that can be done with Agile teams to develop higher levels of self awareness. For example, here’s a Johari Window self-assessment tool:

http://kevan.org/johari

A key element for successful implementation of these exercises is creating an environment of trust where people feel comfortable with being open and honest with others in a small group. Once people have become comfortable with doing that in a small group, they can then take more risks and practice the same behavior outside of that small protected group environment.

Is Agile Like the Steam Engine?

Is Agile Like the Steam Engine? I recently participated in a LinkedIn discussion in which the author of the discussion made a statement that “Agile is by definition a software development methodology”. I didn’t agree with that statement at all…Its unfortunate that the word “Agile” has acquired that connotation in actual usage by a number of people but that’s just sloppy use of terminology (similar to the sloppy use of the word “Waterfall” that I’ve talked about) and its also somewhat narrow thinking.

The author of that discussion defended his statement that “Agile is by definition a software development methodology” by saying that “The Agile Manifesto starts with these words ‘We are uncovering better ways of developing software'”. That statement doesn’t work either in my opinion – I’m sure that was a key motivator behind creating the Agile Manifesto but that was in 2001 which was 12-13 years ago and our concept of what Agile is has grown significantly since that time.

I was trying to think of a good analogy to illustrate this point and somehow I thought of the steam engine. The steam engine was originally invented in 1698 by Thomas Savery who was working on the problem of how to pump water out of coal mines. Thomas Newcomen improved on the design but it wasn’t until Scotsman James Watt improved on the steam engine in the second half of the 18th century that it became truly a viable piece of machinery that helped start the industrial revolution. Even though that started the industrial revolution across the whole world, very few people in the 1700’s would likely imagine that that was only the beginning and the same principles originally used to use to pump water out of coal mines would have a much broader usage in the future including powering nuclear power plants.

(Source: http://americanhistory.about.com/od/industrialrev/p/steamengine.htm)

I think Agile is very similar…

  • The roots of Agile go back a lot further than 2001 – you can very easily trace the roots of Agile to TQM and Lean Manufacturing long before 2001 and the evolution of iterative methodologies like RUP certainly also had an influence. The period prior to 2001 was probably equivalent to pumping water out of coal mines
  • Learning to apply The Agile principles to software development in the Agile Manifesto in 2001 was a real breakthrough that is probably similar to James Watt learning how to apply steam to operate industrial machinery that started the industrial revolution across the world. It had major impact, but that was only the beginning
  • Just as James Watt probably never envisioned the use of steam power in nuclear power plants, the signers of the Agile Manifesto probably never fully envisioned widespread implementation of those principles in many other areas beyond software development

In common usage, some people think that the word “Agile” only applies to software development; to other people, the definition is even narrower and you’re only truly Agile if you’re doing Scrum and doing it strictly by the book with no variation. in my opinion, this really is just sloppy use of terminology and narrow thinking in how the word “Agile” is being used. Our understanding of what “Agile” is is still at a very early stage probably very similar to when James Watt learned how to apply steam technology to operate industrial machinery and limiting our thinking about what “Agile” is may prevent us from imagining new applications and ways of using Agile principles and practices that no one has even dreamed of yet.

Agile Project Manager Job Description

I was recently asked by a company I am working with to create an Agile Project Manager job description. Here’s what I came up with:

Introduction

The Agile Project Manager (APM) is responsible for planning, leading, organizing, and motivating agile project teams to achieve a high level of performance and quality in delivering agile projects that provide exceptional business value to users. The APM may be responsible for managing several concurrent high visibility projects using agile methods in a fast-paced environment that may cross multiple business divisions. The APM may play a number of different roles in actual practice:

  • At an enterprise level, leading and managing large, complex enterprise-level projects consisting of multiple Agile teams and/or requiring integration with other activities outside the scope of the Agile teams
  • At a team level, playing a consultative role to help put in place the appropriate people, process, and tools and coaching members of the team as needed to optimize the efficiency of the project team
  • In situations that require a hybrid Agile approach, using good judgment and skill to develop a project management approach that is suitable for planning and managing the effort to achieve the project goals within designated project constraints

In performing these roles, the APM will be expected to use a high level of knowledge and experience in blending traditional project management principles and practices with an Agile development approach in the right proportions to fit large, complex, mission-critical, enterprise-level projects and with the appropriate level of planning and provide the right balance of agility and predictability.

Essential Job Requirements:

  • Project Planning and Management – Define project scope and schedule while focusing on regular and timely delivery of value; organize and lead project status and working meetings; prepare and distribute progress reports; manage risks and issues; correct deviations from plans; and perform delivery planning for assigned projects
  • Team Management – Assist in team development while holding teams accountable for their commitments, removing roadblocks to their work; leveraging organizational resources to improve capacity for project work; and mentoring and developing team members
  • Product Owner Support – Support the Product Owner in managing customer expectations for project deliverables, managing stakeholder communications, and helping to implement an effective system of project governance
  • Process Management and Improvement – Define and manage a well-defined project management process and champion ongoing process improvement initiatives to implement best practices for Agile Project Management
  • Team building – promote empowerment of the team, ensure that each team member is fully engaged in the project and making a meaningful contribution, and encourage a sustainable pace with high-levels of quality for the team

Qualifications:

  • Solid understanding of software development life cycle models as well as expert knowledge of both Agile and traditional project management principles and practices and the ability to blend them together in the right proportions to fit a project and business environment
  • A proven track record of successfully implementing software or web development projects using Agile methodologies including 8+ years of experience as a Project Manager managing large, complex projects in a high-tech development environment with multi-function teams. PMP preferred
  • Prior experience with SCRUM/Agile methodologies with enterprise-level application development projects. PMI-ACP, CSM, or equivalent preferred
  • Experience overseeing multi-function project teams with at least 10-15 team members including Developers, Business Analysts, and QA Personnel
  • Balanced business/technical background:
    • Sufficient level of technical background to provide highly-credible leadership to development teams and to be able to accurately and objectively evaluate complex project risks and issues
    • Ability to provide leadership to business analysts and collaborate with customers and develop strategies and solutions of high business value

Skills Required:

  • BA or BS or equivalent experience is required; MA or MS is a plus
  • Strong interpersonal skills including mentoring, coaching, collaborating, and team building
  • Strong analytical, planning, and organizational skills with an ability to manage competing demands
  • Strong knowledge and understanding of business needs with the ability to establish/maintain high level of customer trust and confidence
  • Proven ability to lead software development projects and ensure objectives, goals, and commitments are met
  • Solid understanding of and demonstrated experience in using appropriate tools:
    • Agile Project Management tools such as Jira/Greenhopper, Rally, VersionOne or equivalent
    • Microsoft Project, Visio, and all Office Tools
  • Excellent oral and written communications skills and experience interacting with both business and IT individuals at all levels including the executive level
  • Creative approach to problem-solving with the ability to focus on details while maintaining the “big picture” view

To understand the context of this and for more insight into the role of an Agile Project Manager, check out my online training course:

“Mastering Agile Project Management”

Thoughts and Recommendations on Scrum Master Training

This is not a plug for a Scrum Master training course… I was recently asked to provide some thoughts and recommendations on Scrum Master training for a person who was new to the Scrum Master role. This particular individual knew the basic mechanics of how to do Scrum but needed to take the performance of the team to the next level. I want to share my recommendations with you because I think this is a fairly common situation.

  • The biggest problem is that many people don’t understand the full scope of the Scrum Master role. They see it as a passive facilitator role and all you need to know is the mechanics of how to do Scrum. If that’s the way you see it, you can get the standard CSM certificate and call it “done”; I think it is much more than that. (See my recent post on the Scrum Master role):http://managedagile.wordpress.com/2013/08/17/scrum-master-role
  • I thought that the standard Certified Scrum Master (CSM) course would be a waste of time and money for this individual unless it is taught by someone really good who goes beyond the basics. Most CSM courses only cover the basic mechanics of Daily Standups, Sprint Reviews, Retrospectives, etc. and that’s a very small fraction of what a good Scrum Master needs to know, in my opinion.
  • However, I did think it would be worthwhile for this individual to take an assessment of Scrum Master knowledge without going through the standard CSM course – an assessment exam is relatively inexpensive ($100) and that exam will help validate that the individual has the basic Scrum Master knowledge or not and will help to highlight any areas of weakness. Here’s a link for registering to take the Professional Scrum Master Self-Assessment:http://www.scrum.org/Assessments/Professional-Scrum-Master-Assessments/PSM-I-Assessment

What is needed in many cases is an Advanced Scrum Master training course, but there are very few of those offered. Standard CSM courses are available all over the place, but very few people offer an Advanced Scrum Master course that goes beyond the basics because so many people seem to be content to get the CSM certificate and call it “done”.

A good Scrum Master, in my opinion, is passionate about Agile and doing it with a level of excellence. He/she should be somewhat of an evangelist to help others thoroughly integrate Agile/Scrum values, principles, and practices into the way that they work. That’s what is needed, in my opinion. There are many situations like the one I was in where the company was doing the “mechanics” at a basic level and what’s needed is to go beyond that basic level to really dramatically improve the performance of the team. In that kind of situation, you’ve really got to become somewhat of an Agile “zealot” to do it well and one CSM course is not likely to do that.

It requires a strong commitment to ongoing learning and development to become a really good Scrum Master. Essentially, you need to commit yourself to becoming an “Agile Expert”. There are a lot of regularly scheduled Agile events sponsored by Agile groups throughout the world where people share knowledge of what works and what doesn’t work in the real world. Don’t forget that Agile is based on very empirical knowledge… beyond a certain point, there is no textbook that I’m aware of to tell you exactly what to do.

Another course and certification that I think is worthwhile to consider (but not necessarily the first thing to do) would be to get the PMI-ACP certification. ACP stands for “Agile Certified Practitioner” and is a new PMI certification designed primarily for project managers who work in an Agile environment. I have that certification and I think it is worthwhile. Here’s what I like about it:

    • I think the PMI-ACP exam is more rigorous than the CSM exam and the certification has some more rigorous experience requirements that the CSM certification doesn’t require
    • The PMI-ACP certification takes a broader view of Agile not limited to Scrum and covers other related knowledge areas such as Lean and helps you see the “Big picture” of what Agile is all about; where CSM is really focused on Scrum and the mechanics of how to do Scrum

Both have value…you do need to know the mechanics of how to do Scrum, but it’s also worthwhile to see the “big picture” of Agile as well to better understand the principles and practices at a higher level. You will find information on the PMI-ACP certification here:

http://www.pmi.org/Certification/New-PMI-Agile-Certification.aspx

I think certifications have value if they’re used in the right way. Some people seem to use them to “punch a ticket” and call it done. I see certifications as part of a program of ongoing learning. They can be useful to calibrate what you know and don’t know, particularly if you do a lot of self-study as I do; but getting a particular certification should rarely be an end in itself.

Agile Scrum Master Role

I was asked to put together a clear definition of an Agile Scrum Master role for a company I am working with that is new to Agile. I think the standard “textbook” definition of what a Scrum Master does is limited and needs some interpretation and elaboration. It also needs to be expanded with some best practices for Scrum Masters from a variety of sources (see below). Here is what I came up with:

  1. Team Management – A commonly held view of Scrum Masters is that they are only passive facilitators because the team is supposed to be self-organizing. That may be true in an ideal world, but very few teams are really at that level from my experience and even teams that are at a high-level of proficiency can slip back. In my opinion, Scrum Masters have to use what I call “Adaptive Leadership” – if a Scrum Master is only a passive facilitator, he/she is not doing the job effectively in my opinion. He/she has to provide a sufficient level of leadership to help the team get to a self-organizing level and then sustain it without over-managing the team. “Adaptive leadership means providing just enough leadership to fit the situation and nothing more. Here are some specific components of that role:
    • Team Productivity
      • Ensures that the team is fully functional and productive including having the right tools, training, and process flows to maximize team productivity
      • Coaching the Development Team in self-organization and cross-functionality
      • Helping the Development Team to create high-value products
      • Coaching the Development Team in organizational environments in which Scrum is not yet fully adopted and understood
      • Constantly help to improve tools and practices used by the team so that the efficiency is always maintained
    • Remove Impediments
      The Scrum Master should resolve all the impediments so that the team can concentrate on the engineering tasks to be done.
    • Performance Appraisal & Feedback
      The Scrum Master will provide necessary feedback to the team members to help them improve their performance.
    • Resolve Conflicts
      The Scrum Master should be in touch with the team members to sense any conflicts early and resolve them
  2. Process Management – A good Scrum Master, in my opinion, is passionate about Agile and doing it with a level of excellence. He/she should be somewhat of an evangelist to help others thoroughly integrate Agile/Scrum values, principles, and practices into the way that they work.
    • Meeting Facilitator
      Facilitates Daily Scrums and Other Scrum Events to ensure that they are well-organized, time-boxed and productive.
    • Process Master
      The Scrum Master will typically serve as the scrum expert on the team. This means they are responsible for helping the team optimize the use of scrum as the methodology they have chosen to build their software.
      The Scrum Master creates the scrum rules for the project and then coaches the team to follow Agile principles and practices. At the end of the sprint, he needs to ensure that every user story is completed as per the definition of done.
    • Team Interface
      Serves as the primary interface to the team to manage communications with the team and shield the team from disruptive external influences.
    • Planning and Estimation
      Coach the team on estimation practices, lead the team in estimation during the planning meeting, and work with the team to improve estimation and planning process
    • Continuous Improvement
      Leads and facilitates retrospective meetings and champions efforts to improve on the quality, velocity, value to the business
  3. Project Management – The Scrum Master is not really a Project Manager; however, there are some project management skills that are useful in the role. The Product Owner should really own responsibility for the overall success or failure of the project; however, a Scrum Master plays a number of roles in support of the Product Owner in performing the program/project management function.
    • Support the Product Owner
      • Assists the Product Owner with various activities including assisting with backlog as well as project-level and release-level planning
      • Helping to ensure that the items in the backlog are clear and concise
      • Working with the Product Owner to prioritize the items in the backlog
    • Organizational Transformation
      • Leading and coaching the organization in its Scrum adoption;
      • Planning Scrum implementations within the organization;
      • Helping employees and stakeholders understand and enact Scrum and empirical product development;
      • Causing change that increases the productivity of the Scrum Team; and,
      • Working with other Scrum Masters to increase the effectiveness of the application of Scrum in the organization.
    • Radiate Information
      Radiate information or ensure that a team’s progress and successes are highly visible to all stakeholders, including the team itself.

In addition to my own personal experience, I have used the following sources to compile this list:

  1. Scrum Guide – http://www.scrum.org/scrum-guides/
  2. Scrum Master Roles & Responsibilities by Amit Malik – http://amitsinghmalik.blogspot.com/2013/06/scrum-master-roles-responsibilities.html

Developing an Agile Company Culture

Developing an Agile company culture can be a major obstacle to successfully implementing an Agile development approach; however, it doesn’t have to be that difficult. Some people make the mistake of thinking that you have to change the entire culture of a company in order to adopt an Agile development approach. I don’t believe that is either necessary or appropriate in many cases; a company’s culture should be designed around whatever business they are in and that may or may not be well-aligned with implementing an Agile development approach. See my previous blog post on “Agile and Corporate Culture” for more discussion on this:

http://managedagile.wordpress.com/2013/03/30/adapting-an-agile-development-process-to-a-corporate-culture/

Agile works best in companies that are in the business of developing products or where software product development is somehow very directly related to their primary business. In other companies where the relationship is more indirect, it can be much more difficult to implement an Agile development approach because it may not be as well-aligned with the company’s primary business objectives. An example is Walmart…Walmart’s primary business is driven by reducing costs. I’m sure that software development plays some role in that but it is much more indirect than a company like Amazon.com whose business is very directly leveraged by software development. It should be very easy for a company like Amazon.com to implement an Agile development approach and far more difficult for a company like Walmart to do the same thing.

The key point is that since Walmart’s primary business is through conventional brick-and-mortar retail stores, they have to develop a culture that is well-aligned with squeezing costs out of every area of their operations and managing a large number of retail stores very efficiently and effectively. Those are the primary drivers of their business and that may not align very well with an Agile development approach. If you were to set out to implement an Agile development process inside of a company like Walmart, would you try to get them to give up their entire corporate culture and adopt a different corporate culture that is more suitable for hosting an Agile development process? I don’t think so, but there are some fundamental aspects of any company’s culture that can be dysfunctional are most critical to adopting an Agile development approach. Here are a few of what I think are the most important factors:

  • Transparency and Trust – In many large corporations, there is somewhat of a contractual relationship between the business users and the people who deliver Information Technology solutions. The business users may be under intense pressure to reduce costs and want to get firm commitments from the solution providers on the costs and schedules of projects. That is one of the major factors that has can be a big obstacle to implementing an Agile development approach – sometimes it even creates somewhat of an adversarial relationship between the two organizations. The key to getting past that obstacle is:
    1. Companies need to realize that this is not an “all-or-nothing” proposition to totally give up all control of projects to become Agile. There are many ways to blend traditional project management principles and practices with Agile principles and practices to develop the right balance of agility and control. See my blog post on a Hybrid Agile framework here:http://managedagile.wordpress.com/2013/07/22/a-hybrid-agile-development-framework/
    2. Developing a spirit of trust, partnership, and collaboration between the two organizations can require some strong executive-level leadership to break down some of the traditional barriers that exist inside of companies. The strongest driving force for making that happen is that it requires a more collaborative partnership approach to focus on rapid innovation.
  • Focus on Continuous Improvement and Innovation – A focus on process improvement and continuous innovation is certainly not new to Agile. It has been around a long time and many companies have successfully adopted continuous improvement approaches based on Six Sigma and other methodologies. I published my first book in that area called “From Quality to Business Excellence” in 2003. What I found was that in the companies that did Six Sigma well, it may not even be noticeable that it was Six Sigma. They may not have a lot of the hoopla like black belts and green belts that are normally associated with Six Sigma and it was so deeply engrained into the way the company did business, that it may not even have been called Six Sigma.The companies that did it well took a systems thinking approach to adapt it to their business while the more superficial companies simply did it mechanically “by the book” and treated it as just another “Program du jour”. I think a similar thing is happening today with Agile. Companies who take the time and effort to understand Agile at a deeper level and adapt it to their business are probably more likely to do it successfully.
  • Respect for People and Self-organizing Teams – This principle is also not new to Agile. It was a key element of Dr. Deming’s principles that form the basis of the Total Quality Management (TQM) approach and I can remember a strong focus on this when I worked at Motorola in the early 1990’s. It’s another thing like Six Sigma that some companies forget about when the pressure gets intense to deliver business results. They sometimes take a superficial, brute-force approach to try to drive business results rather than taking a systems-thinking approach to understanding the factors that drive business results and the role that people play in achieving those goals.

If you only focus on those three things about a company’s culture, I think you will have a pretty good foundation for implementing an Agile development approach and those three things are somewhat common to all companies regardless of what business they’re in.

By the way, here’s an interesting footnote to this article: Walmart has recognized the importance of e-commerce to their business and has formed a new division called “Walmart Labs” to address that challenge. Here’s an interesting article on that topic:

http://www.technologyreview.com/news/429589/walmarts-new-high-tech-labs-youre-not-in-arkansas-anymore/

Managed Agile Development Framework

I’ve seen many people ask a question like “should I use Agile or Waterfall for a project? That presumes that this is a binary, all-or-nothing choice that you have to choose one or the other and not both. It excludes the possibility that there is a hybrid approach that provides the benefits of both approaches. The Managed Agile Development Framework is an example of a hybrid approach that is very easy to implement

A few years ago I was responsible for managing a large government project that required meeting some defined cost and schedule milestones but the customer wanted to take an Agile approach to defining the requirements. In response to that project, I developed an approach which I call “The Managed Agile Development” framework that would satisfy those two seemingly inconsistent goals.

  • We were able to successfully build a partnership with the government client in which we did a very professional job of managing overall contractual requirements at the “macro-level”, and
  • Within that “macro level” envelope, we were still able to implement a fairly Agile development approach at the “micro-level”

Managed Agile Development Framework

I’m providing a brief description of how it works here (refer to my book for more details). There are two layers in the framework as shown in the diagram above. The “Macro” layer is plan-driven; but it can be as “thick” or “thin” as you want it to be. The “Micro” layer can be any Agile development approach such as Scrum.

  • The macro-level framework is a plan-driven approach, designed to provide a sufficient level of control and predictability for the overall project. It defines the outer envelope (scope and high-level requirements) that the project operates within
  • Within that outer envelope, the micro-level framework utilizes a more flexible and iterative approach based on an Agile Scrum approach that is designed to be adaptive to user needs

Naturally, there are tradeoffs between the level of agility and flexibility to adapt to change at the “micro-level” and the level of predictability and control at the “macro-level”. It is important that both the client or business sponsor and the development team need to agree on those tradeoffs. The framework provides a mechanism for making those tradeoffs by making the “macro-level” as “thick” or “thin” as you want to fit a given situation.

  • Increasing the level of predictability and control requires beefing up the macro-level and providing more detailed requirements at that level and implementing at least a limited amount of change control
  • To increase the level of agility, you can simply eliminate the macro-level altogether or limit it to only very high-level requirements
  • Other elements of the framework can be easily customized or eliminated depending on the scope and complexity of the project and other factors

A question that often comes up is “How do you handle change control?”. The answer to that question is that you have to design enough slack into the milestones at the “macro” level to allow detailed elaboration of requirements to take place in the “micro” level. However, when there is a significant enough change in the “micro” level that would impact achievement of the requirements in the “macro” level, that should trigger a change to the “macro” level milestones. This general approach can be used on almost any project.

Check out my online training courses to learn more about developing a hybrid Agile approach and some case studies that show how it has been used successfully.

Agile and Lessons Learned From the Martial Arts

I was engaged in a discussion on LinkedIn that made me think about the relationship of Agile and lessons learned from the martial arts like Karate – in theory, there should be a lot of similarity:

  • Techniques – There are a wide range of Martial Arts techniques that can be applied in different situations
  • Finesse and Skill – Most Martial Arts require finesse and skill; it’s not just a brute force approach
  • Levels of Skill – There are different levels of skill associated with Martial Arts and it is an ongoing journey to become a “master”

In actual practice; however, I think that Agile principles and practices are at a very low level of maturity compared to Martial Arts (that’s perfectly understandable given that Martial Arts have been around for thousands of years); however, there is a lot we can learn from martial arts that can be applied to Agile:

  • Techniques – Agile has become synonymous with Scrum as the primary methodology for implementing Agile and our knowledge of implementing Agile successfully is heavily defined by the “mechanics” of how to implement Scrum. Surely, there must be more to Agile than that. That’s equivalent to saying that Karate is the only Martial Arts practice when there are many, many others.
  • Finesse and Skill – I’ve seen many companies take a very superficial approach to Agile. They will do a few Agile practices like holding Daily Standups and putting up Kanban Boards and call it Agile. In many cases, if you look under the surface, it’s still just a brute force approach to get things done. They haven’t really fully implemented Agile principles and practices and they haven’t mastered the skill and finesse needed to do it well.
    • People may not be dedicated to Agile teams
    • The company may still rely on overtime, weekend work, and pressure to meet unrealistic deadlines
    • There may be no Product Owner role and the business side may not be well-integrated with the project
  • Levels of Skill – Many people don’t seem to realize that there are different levels of skill associated with Agile (some of those levels aren’t even fully understood yet).
    • There is a wealth of knowledge about how to do almost every aspect of Scrum at the team level but very little is understood about how to scale Agile to an enterprise level and how to integrate it with a business environment that isn’t necessarily well-suited to Agile.
    • There are also still very wide gaps in our understanding of how to blend Agile principles and practices with more traditional project management principles and practices which are often seen as competitive rather than complementary with Agile.

There’s a particular concept from Martial Arts that is helpful to understand the level of maturity we are at in Agile. The concept of “Shu-ha-ri” is a Japanese concept to define different levels of proficiency in Martial Arts:

    • “Shu” means to keep, protect, keep or maintain. During the “Shu” phase, the student builds the technical foundation of the art.
      In “Shu”, the student should be working to copy the techniques as taught without modification and without yet attempting to make any effort to understand the rationale of the techniques of the school/teacher. In this way, a lasting technical foundation is built on which the deeper understanding of the art can be based
    • “Ha” is the second stage of the process. “Ha” means to detach and means that the student breaks free from traditions to some extent.
      In the “Ha” stage, the student must reflect on the meaning and purpose of everything that s/he has learned and thus come to a deeper understanding of the art than pure repetitive practice can allow.
    • “Ri” means to go beyond or transcend. In this stage, the student is no longer a student in the normal sense, but a practitioner.
      The practitioner must think originally and develop from background knowledge original thoughts about the art and test them against the reality of his or her background knowledge and conclusions as well as the demands of everyday life. In the Ri stage, the art truly becomes the practitioner’s own and to some extent his or her own creation.

(Source: Shu-Ha-Ri http://www.aikidofaq.com/essays/tin/shuhari.html)

If you think about our current level of knowledge of Agile as it exists today, I think many people are still struggling with the “Shu” level to understand the mechanics of how to do Scrum and have a long way to go to really get to higher levels of mastery. I’m not sure how many people realize how big this gap is between where we are now and where we need to get to. I think there are many people who seem to think that all there is to know is the mechanics of how to do Scrum at the team level and I think we have hardly scratched the surface of the knowledge that is needed to be known about how to successfully do Agile Project Management.

Martial Arts have been around for thousands of years and there’s still a lot to be learned so its very understandable that our level of knowledge about Agile is at a fairly low level of maturity. For example, here is a very good article written by Patti Gilchrist on the innovations that Bruce Lee has brought to Martial Arts that has some similar thoughts to this article that I really liked: http://www.projectmanagement.com/articles/278838/Of-Martial-Arts-and-Methodology