Tag Archives: Operations

IT Project Agility

Learn more about transforming people, process and culture with the Real Agility Program

Over the years I have done a number of talks for local chapters of the Project Management Institute.  They have covered a range of topics, but one common theme that comes up over and over is that Scrum is not the best Agile method for delivering an IT Project.  I even published a short video on the topic:

Several years ago, I also published a short article describing what Scrum is good for:

What is Scrum good for?

So… if Scrum isn’t so good for IT project work, then what can bring real agility to IT projects?

IT Project Attributes

Most of my work experience prior to running my business was in IT projects in banking, capital markets, insurance and a bit in government and healthcare.  I mention that merely to indicate that my discussion of this isn’t just theoretical: I’ve seen good projects and bad projects.  I’ve been on death-march projects, small projects and massive projects ($1b+).  I’ve dealt with regulatory issues, vendor issues, offshoring issues, telecommuting issues, architectural issues, political issues, and seen enough problems to understand the complexity of reality.

IT projects have some common characteristics:

  1. Like any project, there’s a deadline and a scope of work and a budget.  These things don’t work well with Scrum.  It’s possible to force them to fit together, but you lose a lot of what makes Scrum effective.
  2. IT (as opposed to, say, tech startups) tends to use more mature technology platforms.  Scrum is neutral about technology, but there are other Agile methods that address this type of technology more effectively.
  3. IT Projects are often not the only thing going on in the technology organization.  In particular, operations and user support add to IT project complexity, and require different “classes of service” than Scrum provides.
  4. The issues that I mentioned above such as regulation, vendors, offshoring etc. are also common attributes of IT projects.  Scrum makes harsh demands on an organization that challenge the approach to dealing with these issues.  The change required to accommodate Scrum may not be worth it.

The Bad News about IT Project Agility

The whole project orientation to IT work is questionable.  It’s just not a good fit.  In most mid- to large-size organizations, IT does two things: it provides technology services to the rest of the organization, and it provides technical product development capacity to lines of business.  For example, upgrading the office wi-fi routers and adding a new payment type to the online customer portal, respectively.  The work of the IT department, therefore, falls into several different categories:

  1. New artifacts that need to be created.  Usually this is the stuff like coding algorithms and other business logic, creating new databases, configuring purchased systems, etc.
  2. Repetitive activities that need to be sustained for a period or indefinitely, or which occur on-demand but at irregular times.  For example, running a nightly batch process or deploying an update to a production environment.
  3. Quality problems that need to be fixed.  Defects and production problems are the obvious categories here, but also quality problems that are causing user confusion or time wastage.
  4. Obstacles to work that need to be overcome.  Often obstacles come from outside the project team in the form of interruptions. Other forms of obstacles can be unexpected bureaucracy, shifting funding, problems with a vendor, etc.
  5. Calendar events that need to be accommodated.  Milestones in the project, particularly regulatory milestones are crucial in IT project work, there are many other types such as all-hands meetings, statutory holidays, hiring or contract end dates, etc.

Of these, only repetitive activities and calendar events fit well into a project perspective.  The others typically have a level of uncertainty… complexity… that makes it very difficult to approach with the project perspective of fixed deadlines and scope.

On the other hand, Scrum only really handles new artifacts and obstacles directly, and quality problems indirectly.  These are the kinds of activities that are the focus of product development.  Repetitive activities and calendar events are anathema to the core Scrum framework.  If I think about this from a scoring perspective, Scrum supports these kinds of work as follows (-5 means totally counter, 0 means no impact, +5 means total support):

Scrum Support for IT Project Work Types:

  1. New artifacts: +5
  2. Repetitive activities: -2
  3. Quality problems: 0
  4. Obstacles: +4
  5. Calendar events: -5

SCORE: +2 – barely positive impact on IT project work!!!

The bad news, therefore: neither a project orientation nor Scrum really cover all the needs of an IT project environment.

(For more information about Scrum, check out our “Rules of Scrum” page, our “Scrum Diagram” article, and our highly-regarded Certified ScrumMaster learning events.)

Alternatives to Scrum

There are many, but these are my three favourite alternatives: Extreme Programming, Kanban and OpenAgile.  All three of them cover the five types of work more effectively than Scrum.  All three of them are oriented to more generic types of work.  After describing each briefly, I’ll also mention which one is my top choice for IT project work.

Extreme Programming for IT Project Work

Historically, Extreme Programming (XP) emerged in an IT Project context: the famous C3 project at Chrysler.  This approach to IT project work has many things in common with other approaches to agility (which are described in the Agile Manifesto).  XP allows the five types of work as follows:

New artifacts are the core of XP and are usually expressed as User Stories.  This is common to Scrum and many other Agile methods.  These are typically the features and functionality of a system… the scope of the project work.  XP does not make any strong assertions about the size or stability of the backlog of new artifacts and as such can accommodate the project orientation in IT with relatively fixed scope.

Repetitive activities are not explicitly addressed in XP, but nor is there anything in XP which would cause problems if an XP team is required to do operational or support work which is the source of most repetitive activities in an IT environment.

Quality problems are addressed directly with both preventative and reactive measures.  Specifically, Test-Driven Development, Acceptance Test-Driven Development are preventative, and Refactoring and Continuous Integration are reactive.  XP has a deep focus on quality.

Obstacles are not directly addressed in XP, but indirectly through the XP value of courage.  Implicitly, then, obstacles would be overcome (or attempted) with courage.

Calendar events are not addressed directly for the most part with the exception of release planning for a release date.  However, the stuff related to other calendar activities is not directly handled.  XP is less antagonistic to such things than Scrum, but only by implication: Scrum would often put calendar events in the category of obstacles to be removed to help a team focus.

XP Support for IT Project Work Types:

  1. New artifacts: +5
  2. Repetitive activities: 0
  3. Quality problems: +5
  4. Obstacles: +2
  5. Calendar events: +1

SCORE: +13 – moderate to strong positive impact on IT project work!

Summary: much better than Scrum, but still with some weaknesses.

Kanban for IT Project Work

Kanban is different from most other approaches to agility in that it is a “continuous flow” method, rather than an iterative/incremental method.  This distinction basically means that we move packages of work through a process based on capacity instead of based on a fixed cadence.  Kanban asks that we visualize the current state of all work packages, limit the amount of work in progress at any stage in our delivery process, and use cadences only for iterative and incremental improvement of our process (not our work products).

Kanban is much gentler than Scrum or Extreme Programming in that it does not require leader-led reorganization of staff into cross-functional team units.  Instead, we identify a service delivery value stream and leaders manage that stream as it currently operates.

You can read a somewhat slanted history of Kanban here, and a good comparison of Kanban and other Agile methods here.

New artifacts in Kanban are supported, and certainly welcome, but Kanban does not seem to acknowledge the problem of formal complexity (creativity, problem-solving, human dynamics) in the creation of new artifacts.  There are good attempts to apply statistical methods to the management of new artifacts, but their fundamentally unknowable cost/end (undecidable problem) is not really effectively addressed.

Repetitive activities are handled extremely well in Kanban including different classes of service.  Repetitive activities are handled well partly as a result of the history of Kanban as a signalling system in manufacturing environments.

Quality problems are handled similarly to new artifacts: supported, welcome, and even possibly addressed in the cadences of continuous improvement that Kanban supports.  However, quality problems are another area where technical complexity makes proper analysis of these activities difficult.

Kanban relegates the handling of obstacles to the manager of service delivery.  There is no explicit support for strong organizational change efforts.  In fact, Kanban discourages “transformative” change which is sometimes required given the problem of Nash equilibriums.

Kanban works well with Calendar events by treating them as activities with a particular class of service required.

Kanban Support for IT Project Work Types:

  1. New artifacts: +3
  2. Repetitive activities: +5
  3. Quality problems: +3
  4. Obstacles: 0
  5. Calendar events: +5

SCORE: +16 – strong positive impact on IT project work!!

Summary: even better than XP, easier to adopt. (Actually, almost anything is easier to adopt than XP!!!)

OpenAgile for IT Project Work

OpenAgile is an obscure non-technology-oriented method based on the work I and a few others did about 10 years ago.  The OpenAgile Primer is the current reference on the core of the OpenAgile framework.  OpenAgile has been applied to general management, small business startups, sales management, mining project management, emergency services IT, and many other areas of work.  I’m partial to it because I helped to create it!

OpenAgile emerged from consulting work I did at CapitalOne in 2004 and 2005 and work I did with my own business in 2006 and 2007.  A great deal of the older articles on this blog are forerunners of OpenAgile as it was being developed.  See, for example, Seven Core Practices of Agile Work.

The types of work listed above, are indeed the core types of work described in OpenAgile.  As such, OpenAgile fully supports (nearly) all five types of activities found in IT projects.  However, OpenAgile is not just a work delivery method.  It is also a continuous improvement system (like Kanban and Scrum) and so it also assumes that a team or organization using OpenAgile must also support learning.  This support for learning means that OpenAgile does not over-specify or give precise definitions on how to handle all five types of work. Thus, my scores below are not all +5’s…

OpenAgile Support for IT Project Work Types:

  1. New artifacts: +4
  2. Repetitive activities: +4
  3. Quality problems: +4
  4. Obstacles: +4
  5. Calendar events: +4

SCORE: +20 – very strong positive impact on IT project work!!!

Summary: OpenAgile is the best approach I know of for general IT project environments.

Conclusion

Regrettably, I wouldn’t always recommend OpenAgile – there are just too few people who really understand it or know how to help an organization adopt it effectively.  If you are interested, I’d be happy to help, and we can certainly arrange private training and consulting, but mostly I would recommend Kanban to people interested in taking the next step in effectiveness in IT projects.  Please check out or Kanban learning events and consider registering for one or asking for us to come to your organization to deliver training, coaching or consulting privately.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Definition of DevOps and the Definition of “Done” – Quick Links

Learn more about transforming people, process and culture with the Real Agility Program

I was poling around for a good definition of DevOps and found a thoughtful article written by Ernest Mueller called What is DevOps?  Highly recommended reading as it includes lots of insight about the relationship between Agile and DevOps.  FWIW, I feel that the concept of the Definition of “Done” is Scrum’s own original take on the same class of ideas: breaking down silos in an organization to get stuff into the marketplace faster and faster.  I even talked about operationalizing software development back in 2004 and 2005 as a counterpoint to the project management approach which puts everyone in silos and pushes work through phase gates.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Best Agile Advice Articles – Ten Year Anniversary!

Learn more about transforming people, process and culture with the Real Agility Program

Agile Advice was started in 2005.  In ten years, we have published over 850 articles (an average of just about 2 per week!).  Here are some collections of the ten “best” articles.  I hope you enjoy looking back at (or discovering for the first time!) some of the things that have made this such a great joy for me.

Ten Most Popular Agile Advice Articles

  1. How Two Hours Can Waste Two Weeks (75,000+ visits)
  2. The Seven Core Practices of Agile Work (25,000+ visits)
  3. Eight Barriers to Effective Listening (17,000+ visits)
  4. Seven Essential Teamwork Skills (17,000+ visits)
  5. 24 Common Scrum Pitfalls Summarized (15,000+ visits)
  6. Mentoring and Coaching: What is the Difference? (14,000+ visits)
  7. Wideband Delphi Estimation Technique (14,000+ visits)
  8. The Pros and Cons of Short Iterations (13,000+ visits)
  9. Three Concepts of Value Stream Mapping (13,000+ visits)
  10. Agile Work and the PMBoK Definition of Project (11,000+ visits)

Ten Most Commented Upon Agile Advice Articles

  1. 24 Common Scrum Pitfalls Summarized (19 comments)
  2. Agile Becomes Easier with Useful Tools (12 comments)
  3. Important Words about Scrum and Tools (9 comments)
  4. The Skills Matrix and Performance Evaluation on Agile Teams (9 comments)
  5. The Definition of Done is Badly Named (8 comments)
  6. How Two Hours Can Waste Two Weeks (7 comments)
  7. Agile is Not Communism (7 comments)
  8. Agile Tools vs. Agile Books (6 comments)
  9. The Decline and Fall of Agile and How Scrum Makes it Hurt More (5 comments)
  10. The Planning Game: an Estimation Method for Agile Teams (5 comments)

I also want to acknowledge that there are a number of other contributors to Agile Advice besides me (Mishkin).  These contributors are all experts, all have great experiences, and all are fantastic people to know.  I’m grateful for their contributions since they have all made Agile Advice a better place to browse!

Five Most Frequent Contributors (of Articles, besides Mishkin)

  1. Paul Heidema (34 articles)
  2. Travis Birch (24 articles)
  3. Christian Gruber (19 articles)
  4. Mike Caspar (16 articles)
  5. Shabnam Tashakour (13 articles)

Plans for the Future – Five Top Ideas for Series

  1. Essays on each of the Values and Principles of the Agile Manifesto
  2. Summary articles of several Agile methods including Scrum, OpenAgile, Kanban, Crystal, XP, and others
  3. Real Agility Program case studies
  4. Reviews of other scaling / enterprise Agile frameworks such as Disciplined Agile Delivery, Large Scale Scrum, Enterprise Scrum
  5. New guest articles from thought and practice leaders.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

The Real Agility Program – Execution and Delivery Teams

Learn more about transforming people, process and culture with the Real Agility Program

Execution IconIn a recent post, Mishkin outlined the Leadership Team component of the Real Agility Program.  While the Leadership Team track focuses on developing leadership capacity for sustained transformation, The Execution track focuses on launching and developing high-performance project, product and operational teams.  This track is the one that most of our clients use when they run Agile pilot programs and is a critical component of getting quick wins for the organization.

Groundbreaking works such as The Wisdom of Teams (Katzenbach & Smith), The Five Dysfunctions of a Team (Lencioni) and Drive (Pink) have served well to distill the essential requirements of high-performance teams.  Scrum, Kanban, and OpenAgile are proven frameworks that optimize the value of teams and create the necessary working agreements to help teams reach that high-performance state.

The Delivery Team track of the Real Agility Program creates new, cross-functional, multi-skilled, staff-level teams of willing individuals.  These teams are responsible for delivering value—business results and quality.  Individuals are committed to the performance of the team and the organization.  Teams develop the capacity to self-organize and focus on continuous improvement and learning.  A team is usually composed of people from various roles at the delivery level.  For example, and IT project team might be composed of people whose previous* roles were:

  1. Project manager
  2. Business analyst
  3. Software developer
  4. Tester
  5. Database developer
  6. Team lead
  7. User experience lead
  8. Intern

* These roles do not get carried into the new delivery team other than as a set of skills.

The track begins with establishing pre-conditions for success including executive sponsorship, availability of team members and management support.  Team launch involves a series of on-the-job team development workshops designed to enable the teams to create their own set of values, working agreements and high-performance goals.  Teams are guided in the creation of their initial work backlogs, defining “done”, estimation and planning and self-awareness through the use of a collaborative skills matrix.  The teams are also assisted in setting up collocated team rooms and other tools to optimize communication and productivity.

Qualified coaches assist the teams to overcome common issues such as personal commitment, initial discomfort with physical colocation, communication challenges of working with new people in a new way, management interference and disruptions and appropriate allocation of authority.  This assistance is delivered on a regular schedule as the team progresses through a series of steps in the Execution track process.  Usually, these steps take one or two weeks each, but sometimes they take longer.  A team that needs to get to a high-performance state quickly might go through the entire program in 10 or 12 weeks.  In an organization where there is not the same urgency, it can take up to a year to get through the steps of the track.

The coaches for this Execution track also help management to resist and overcome the strong urge to manage the problems of the teams for them.  In order to develop through the stages of team development, teams need to be effectively guided and encouraged to solve their own problems and chart their own courses towards high-performance.

The goal of the Execution track of the Real Agility Program is to help the team go through the stages of forming-storming-norming and set them up to succeed in becoming a high-performance team.  Of course, to do this requires some investment of time.  Although the Execution track is meant to be done as on-the-job coaching, there is a 5% to 20% level of overhead related to the Real Agility Program materials themselves.

See also the article on the Recommendations component of the Real Agility Program.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Job Opportunity at Berteig Consulting Inc.

Learn more about transforming people, process and culture with the Real Agility Program

Berteig Consulting is seeking Operations/Administrative Assistant.
The successful candidate will be responsible for the duties listed below.

Customer Service:
-answering the telephone
-responding to requests through email or telephone
-assist clients with the certification process
-maintaining client database

Office/Administrative:
-organization and maintenance of office space
-light accounting and finance management
-assisting team in achieving company goals
-book venues for courses and seminars.
-assisting team with inquiries about pay-roll or benefits
-performing other administrative duties

The candidate should be motivated, detail oriented, and highly organized. Berteig Consulting encourages truthfulness, learning and innovation, and is seeking a candidate who shares these values and will implement them in this role.

Please send your resume to operations@berteigconsulting.com with the position as the subject and call directly to our office at 905-868-9995 and ask for Paul Heidema.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail