Agile and The Design Sprint

This week's Auspicious Agile video blog takes a look at the Google Ventures Design Sprint.  We cover several applications including Venture Capital, Innovation Labs, Hackathons, and Agile Product Teams.

The Culture Change of DevOps (Video Blog)

This week's Auspicious Agile Video Blog takes a look at the culture change of DevOps. DevOps requires more than just adopting tools, it also requires changes in culture and the way we work. Here we look at several culture aspects in DevOps to consider.

Here are some of the links and resources mentioned in the video blog:

- Xebia Labs periodic table of DevOps - https://xebialabs.com/periodic-table-of-devops-tools/

- Phoenix Project by Gene Kim - http://www.realgenekim.me/

- Dan Pink Drive - https://www.youtube.com/watch?v=u6XAPnuFjJc

- Auspicious Agile first blog on culture change of DevOps - https://auspiciousagile.com/2016/02/20/the-culture-change-of-devops-and-your-career/

- Mirco Herring, DevOps Leadership Culture - https://notafactoryanymore.com/tag/devops-culture/

SAFe Agile Portfolio - CapEx and OpEx

This week's Auspicious Agile video blog looks at the Scaled Agile Framework (SAFe4) Portfolio Level - CapEx & OpEx.  A practitioner's perspective on the recent SAFe and Dean Leffingwell article on the topic.  CapEx & OpEx are accounting and financial terms, but they are very relevant for the enterprise Agile practitioner.  Find out how in this week's video blog.

A Tale of Two (Lean) Start-ups

This week's Auspicious Agile Video Blog takes a look at two real start-up companies.  We will look at how the principles of Lean Start-up (think Agile for Businesses) applies to each of the companies.  We will see where each company used Lean Start-up principles and where they failed to do so.

Scaled Agile Framework 4.0 - A Practitioner's Perspective

This week we take a look at the new version of SAFe 4.0. I will give a practitioner's perspective on the changes and updates, covering interesting and noteworthy areas. SAFe 4.0 represents a significant update and is beneficial to learn about if you are or plan on scaling Agile.

Agile and Martial Arts!?

Agile & DevOps. How are they related?

Personal Agile

As you go about your day-to-day life you can use Agile methods to be more effective. Here are some thoughts to keep you Agile, flexible, and successful:

1. Flexibility in your goals

As you set your goals, start by building in some flexibility in your goal setting. Let’s consider a case where you may be considering expanding your business into a new market. While it makes sense to set some milestones to achieve market entry, it also makes sense to leave room to be flexible in your market entry approach.

For example: It may make sense to set up a new business entity in the market, but it may also make more sense to work with local partners already in the market. Leaving yourself some flexibility in achieving your milestones and goals increases your likelihood of achieving your goals and resolutions.

2. Adapting and adjusting your personal backlog

Just like the way we set up a Scrum Product Backlog or in an Agile scaling context a Program Backlog in planning to meet your goals and resolutions create a personal backlog. This builds on the first point as it helps you to visualise your goals and prioritise them. Having a personal backlog in place also allows you to prioritise your goals and make trade-offs if you aren’t able to achieve everything according to your initial plan (and of course plans do change).

For example maybe you want to gain a new professional certification, start exercising again, and travel more to a new region. Two month’s into your plan you may realise that you won’t be able to maintain your exercise routine and increase your travel to the new region. In that case you may need to update your backlog to incorporate a new type of exercise that you haven’t done in the past. Or you may need to look at the priorities in your personal backlog and decide whether travel to the new region is as important to you as being able to continue your exercise program. Having a personal backlog enables you to be flexible.

3. Limit your WIP

Limiting Work in Process (WIP) is a Lean principle that we see in Agile in the form of the sprint backlog (which limits the work in process every 2 – 4 week time box / sprint). Limiting your personal WIP will help you to focus on what is really important. Do you have new family commitments, broader responsibilities in the work place, and want to continue your education. These are all great goals, but trying to do everything at the same time makes it unlikely you will do anything very well.

So you may choose to focus on those new family commitments during the next month or next quarter (we can think of this as a sprint goal or in Scaled Agile a Program Increment Objective). During the next month or next quarter you may increase your focus on executing on those new workplace responsibilities (of course you will have probably done some initial planning during the previous month or quarter). Finally you may tackle that goal of continuing your education by enrolling in a Masters Programme in the second half of the year.

By limiting WIP you are able to focus on a limited set of things (stories) in your backlog. By doing this you can benefit from reduced task switching and achieve some early wins in key personal areas that will help to encourage you to continue in other areas. Limiting WIP is a key approach to help you to achieve your goals!

4. Use a Kanban Board

A Kanban board is something that allows you to visualise your tasks and activities. There is an example below, but you can name the columns whatever you like.

For example when I moved from the US to Asia, I used a Kanban board to coordinate all of the activities. The columns were Ready/Blocked/In-Progress/Done. Using this method I could visualise all of the activities I needed to do like packing and shipping, finding housing, and updating mailing information. Using the Kanban board allowed me to effectively manage a complex move, and I actually still use one to track my day-to-day activities.

In Summary

Applying a few Agile principles to your planning can help you to be more successful in achieving your goals. Namely, by maintaining flexibility in your goals, creating and adapting your personal backlog, limiting WIP, and visualising your tasks with a Kanban board, you will be well on your way to a successful and happy life.

Until next time, Stay Agile!

Agile 101

Agile Scaling - Scrum-of-Scrums and Nexus

More Agile Scaling Methods – This week DAD and Spotify – Mandarin Chinese

Coverage of DAD and Spotify Agile Scaling Methods in English with Chinese translation.

DAD和Spotify的敏捷缩放方法对英语的覆盖面与中国的翻译。

More on Agile Scaling - This week DAD and Spotify

A few notes on this week's video blog:

1. A good reference on Communities of Practice can be found here
2. The primary and secondary roles in DAD can be found here
3. More background on the Spotify method can be found here

Agile Scaling - SAFE vs LESS

An Optimistic View of Agile Adoption in Asia

To address the potential for Agile adoption in Asia I will look through the lens of multiple Agile methods. The methods considered will include Scrum, Kanban, XP, SAFe, and other Agile Scaling approaches. Asia is a very diverse region, and has to be looked at from many angles to get a picture of the potential for Agile adoption. With this in mind let’s take a look at Agile adoption in Asia.

Asia is not monolithic

It is important to remember that Asia is not monolithic or homogeneous. China is different from ASEAN, India, Japan, and Korea. Countries in ASEAN differ, Singapore is not the same culturally as Thailand or Indonesia. To look at Asia as one monolithic place is not an accurate or informed view.

If we take some examples: Singapore is actively moving towards Agile methods and new technology in its “Smart Nation Initiative”. Thailand has a very active Agile community and many companies have already adopted the use of Agile methods.

China has massive companies and IT departments in the thousands of people. While this can be a challenge for launching a Scrum team, Agile Scaling methods like SAFe have the potential to do very well in the China market. I liken the “leapfrog” potential in the China market to what occurred in Africa in the adoption of cellular technologies and “leapfrogging” over land lines.

Malaysia and Indonesia have been slower in movement towards Agile methods. Korea and Japan have very strong and unique cultures that make it difficult for outsiders to introduce new methods, but the potential for Agile still exists in these markets as well. Japan is the home and originating point of Lean (the Toyota Production System) after all, which is a key foundation for Agile methods.

In South Asia India has been working with Agile methods for years and outsourcing for US and European companies. Many Indian companies establish dedicated teams for Agile methods and adopt Agile methods quite successfully. Sri Lanka is also coming onto the world scene since its internal environment has stabilized and there too some early Agile adoption is taking place. I encountered several companies from Sri Lanka that were very familiar with and / or using Agile methods at the 2014 Gartner Gold Coast IT Symposium in Australia.

Education system in Asia

A criticism of the education system in Asia is that it focuses too much on grades and rank. The argument is that this means there is a lack of creativity which is needed for business agility, Design Thinking, and creative solutions.

My wife a teacher by training in the US came to Singapore on a Fulbright Fellowship to study the education System. One of her findings was that even though in past generations the education system was very focused on grades and rank, that there is more of a move now towards creative thinking and creative problem solving in the schools.

In fact innovation in Asia overall is on the increase. In 2014, China actually accounted for some 32.1% of worldwide patent filings. This can be taken as an indication of innovation and creativity, which is required to create new patents. Shenzhen in southern China is a good example of a Chinese modern hub of innovation.

The overall trend in Asia is toward greater creativity and innovation. This also follows from ancient culture and history in Asia. In China much innovation originated including: gun powder, the compass, paper, and golf among many.

Outsourcing – Reducing Costs

There have been some interesting points made on this topic in an article I recently read. It is interesting to note that in the US outsourcing and cost reduction are a constant focus in companies and IT (which is often viewed as a cost center). In particular a point was made around a low cost Scrum / Agile adoption mentality in Asia. Another point was made around “Agile Project Management” methods being taught as a low cost low effort way to try and adopt Agile.

I think it is valuable to address these points. From experience in the US market I know that it is true that low cost, low effort transitions to Agile are often attempted by simply training Project Managers and developers on Scrum, and changing little else in the organization.   However, I want to point out that Scrum actually includes a project management framework (managing risks, updating on progress, etc…). This is important because it points to the alignment of managing projects and using Agile methods, these two are not contradictory but rather an evolution of methods.

When done properly it is quite possible to help those who have been traditional project managers to work in the context of an Agile organization, and in fact in many cases this is very necessary. For example in the SAFe framework for scaling Agile the role of the Release Train Engineer (RTE – Uber ScrumMaster) can often be effectively played by someone with traditional project management experience (skills like seeing dependencies, and coordinating large groups). The approach to leading becomes a servant leadership approach.   But, the skills obtained in a project management context are still valuable.

Culture

I have seen many comments that suggest that culture in Asia is not compatible with Scrum and Agile. A focus on what is best for the community over the individual is a feature of Chinese culture. This focus on community lends itself to the team aspects of Agile. As I have mentioned in prior blog posts on my Blog AuspiciousAgile.com the community aspects and focus common to many Asian cultures lend themselves very well to the team focus and empowered teams of Agile and Scrum.

Hierarchy

A common observation is that the hierarchy that exists in much of Asian culture is a challenge to Agile adoption. I think this is a valid point. However, I think this is a challenge but not an insurmountable one.

Let’s take the US where Agile adoption is high and steadily increasing as an example. In the US individualism does not align with the team focus of Agile. Many developers and others are focused on what is best for them before they are concerned about what is good for the team. But Agile is still workable in the US. Organizations are able to overcome this challenge in the US and successfully adopt Agile.   Similarly Asia’s social hierarchy does not lend itself to Agile’s servant leadership model, but it is not insurmountable.

In a “Leading SAFe” class that I was teaching recently one participant commented that they have experienced many very successful Agile adoptions in Asia. The comment was that success really depended more on the individual organization than it did on only the broader cultural factors. While I don’t want to downplay broader cultural forces, I think that organizational culture and values can still provide for successful Agile adoption in most countries in Asia.

In Summary 

While there are challenges to adoption of Agile in Asia, I do not see any of them as insurmountable.   Similarly in the US there were cultural aspects (individualism) that are not necessarily aligned with Agile adoption. However, in spite of these cultural challenges Agile adoption has still moved forward in the US. I see no reason that the cultural challenges to the adoption of Agile methods in Asia can not also be overcome.

An Agile Start to the New Year

Hello and Happy New Year!  In looking forward to the New Year, setting goals, and making resolutions here are some thoughts to keep you Agile, flexible, and successful:

1.  Flexibility in your goals

As you set your goals for the New Year, start by building in some flexibility in your goal setting. Let's consider a case where you may be considering expanding your business into a new market.  While it makes sense to set some milestones this year to achieve market entry, it also makes sense to leave room to be flexible in your market entry approach.

For example:  It may make sense to set up a new business entity in the market, but it may also make more sense to work with local partners already in the market.  Leaving yourself some flexibility in achieving your milestones and goals for this year increases your likelihood of achieving your goals and resolutions.

2.  Adapting and adjusting your personal backlog

Just like the way we set up a Scrum Product Backlog or in a SAFe scaling context a Program Backlog in planning to meet your New Year's goals and resolutions create a personal backlog. This builds on the first point as it helps you to visualise your goals and prioritise them.  Having a personal backlog in place also allows you to prioritise your goals and make trade-offs if you aren't able to achieve everything according to your initial plan (and of course plans do change).

For example maybe you want to gain a new professional certification, start exercising again, and travel more to a new region.  Two month's into the new year you may realise that you won't be able to maintain your exercise routine and increase your travel to the new region.  In that case you may need to update your backlog to incorporate a new type of exercise that you haven't done in the past.  Or you may need to look at the priorities in your personal backlog and decide whether travel to the new region is as important to you as being able to continue your exercise program.  Having a personal backlog enables you to be flexible.

3.  Limit your WIP

Limiting Work in Process (WIP) is a Lean principle that we see in Agile in the form of the sprint backlog (which limits the work in process every 2 - 4 week time box / sprint). Limiting your personal WIP this New Year will help you to focus on what is really important. Do you have new family commitments, broader responsibilities in the work place, and want to continue your education. These are all great resolutions and goals, but trying to do everything at the same time makes it unlikely you will do anything very well.

So you may choose to focus on those new family commitments during the first month or first quarter (we can think of this as a sprint goal or in SAFe a Program Increment Objective).  During the second month or second quarter you may increase your focus on executing on those new workplace responsibilities (of course you will have probably done some initial planning during the first month or quarter).  Finally you may tackle that goal of continuing your education by enrolling in a Masters Programme in the second half of the year.

By limiting WIP you are able to focus on a limited set of things (stories) in your backlog. By doing this you can benefit from reduced task switching and achieve some early wins in key personal areas that will help to encourage you to continue in other areas. Limiting WIP is a key approach to help you to achieve your goals and resolutions in the New Year!

In Summary

Applying a few Agile principles to your planning for the New Year can help you to be more successful in achieving your goals.  Namely, by maintaining flexibility in your goals, creating and adapting your personal backlog, and limiting WIP you will be well on your way to a successful and Happy New Year.

Have a Happy and Prosperous New Year, and Stay Agile!

Agile Contracts

Pointers on Enterprise Agile Transformation

Hi All,

This week I want to discuss some pointers to being successful with Enterprise Agile from my experience:

Program and Portfolio Planning

First when it comes to Agile Program and Portfolio planning it can be very valuable to align program milestones with team level iterations and releases.  This can be particularly valuable when a company or organisation is working with a vendor that uses Agile iterations and needs to align this to their internal program and project milestones.  By aligning with Agile iterations and releases communication between the management team and the development team(s) or vendors can be made much clearer.

For example if a vendor will release a mobile user interface in its next iteration, the program and portfolio management teams can align their milestones for delivering mobile access to the upcoming vendor iteration or release.  This also allows an organisation to still have their Agile development teams and vendors responsible to certain delivery goals and milestones.  This approach also maximises visibility by allowing management teams to track how iterations required for their upcoming milestones are progressing, and increases predictability as a result.

Budgetary Tracking and Estimates

That said, the second pointer I would like to discuss is how to budget and estimate for an enterprise Agile program.  Traditional budgeting provides a set amount of money for the delivery of set features in a set timeframe.  However, with an Agile program and Agile teams there needs to be flexibility in the creation of product backlogs of user stories, and backlogs of features.  If the Agile teams are required to fix all of their features at the start of the project for budgetary purposes, the organisation loses one of the key benefits of Agile which is the ability to respond to the market quickly and flexibly.

In order to respond to the market and retain flexibility a good approach is to budget based on a certain set of features of a certain size (when I mention size I am referring to the Agile practice of T-Shirt sizing to facilitate relative estimating), but not to fix the exact features in advance.  For example a company may budget for 5 large features over the next 6 months.  From experience (understanding team velocities and hours spent working on large features) they may know it takes roughly $100k to deliver one large feature.  So to deliver 5 large features in the next 6 months they may budget $500k.  Or if planning out for the year they may budget $1m for 10 large features over the next 12 months.  By planning this way if the company needs to swap a key large security feature for a large mobile feature 3 months into the project their budgeting still remains accurate, while their teams and Product Owners have the flexibility to respond to the market.

Organisational Change

The third pointer is in how to lead an Enterprise Agile program.  I have often heard the advice that when an organisation moves to Enterprise Agile, that they should just make all of their Project Managers into ScrumMasters and magically they will have Agile teams.  The problem with this is that traditional project management and leading Agile Programs requires an entirely different approach to leadership. While Agile programs require a servant leadership approach (serve through leadership, and lead through serving the teams) traditional project management is generally more command and control.

When a command and control project manager is made into a ScrumMaster, or Agile Program Manager the results are generally not healthy.  Instead of empowering teams the ScrumMaster or Agile Program Manager assigns all of the teams’ work and demands that it be finished on an assigned schedule.  This takes away any empowerment the team may have enjoyed as a result of becoming an Agile team in an Agile Enterprise (as well as taking away flexibility and agility).  A key pointer here is to assess each traditional project manager, and leader in the organisation.  Some may adapt well to a servant leadership approach.   Others, may not and may need to find different roles, or may simply be more comfortable in a non-Agile organisation.  Identifying this early on and shifting people to roles where they will be successful is a key organisational change factor to enable successful Enterprise Agile.

I hope some of these pointers and points have been useful.  These are only a few that come to the top of my mind in thinking about avoiding pitfalls in transitioning to an Enterprise Agile organisation.  Hopefully food for thought, and useful advice for avoiding common Enterprise Agile adoption pitfalls.

Until next time, Stay Agile!

John.

Is it Really that Hard to Scale Agile?