Thursday, 23 October 2014

Nuances for Agile Budgeting

Hi All,
This week I would like to revisit Agile budgeting.  In the last Auspicious Agile video blog post we discussed some approaches that can be used to budget for Agile projects.  This week we will look at some nuances that are helpful to consider when budgeting for Agile projects. 
Velocity:
First let's start with how we calculate velocity.  In the last blog post I talked about a method that can be used to derive a best case, worst case and most likely case for budgeting an Agile project or initiative.  The foundation is calculating velocity (velocity = distance / time).  We represent distance as the amount of work to be done (points), and time as the length of the iterations (sprints).  Now we can calculate our budget based on an average velocity, which is a velocity that is derived over time by looking at several sprints done by a team(s) over time.  For example if we have 5 sprints of history to look at and the velocities were 25, 50, 30, 40, and 10 points the average velocity would be 31.
However, it isn't necessary to use average velocity to make budget projections.  You could assume a velocity (maybe because you don't have the iteration history to calculate average velocity, or maybe because the historic data is not representative.  For example in the example above one of the sprints only had 10 points.  That may be because there was a holiday, or team members sick or for some other reason.  So in some cases it may be desireable to make budget projections based on an assumed velocity, maybe in our previous case assuming 40 would make more sense than using the actual average velocity of 31.  Of course if your team has no historical information to base velocity projections on, your team would also want to make an assumption about what the velocity might be (an approach used by the Scaled Agile Framework) and refine that number later.  Maybe you start by assuming 5 points per day for a two week sprint, or 50 points per sprint as the team velocity (make sure to factor in the number of team members when you make your assumption).  
T-Shirt Sizing:
Another consideration is for using the T-Shirt sizing "Price per story" method of budgeting for Agile initiatives.  Some teams may not be familiar with how to T-Shirt size or use relative estimating.  The key is not to focus on getting too detailed on estimates, rather the focus should be to group things in groups that are relatively of the same size.  For example, if you have a coffee cup and you have a bottled water and I ask you to tell me exactly how tall each one is, you will have a very hard time doing this without an accurate measuring device (i.e. ruler).  Again if there is a pile of rocks and I ask you to tell me the exact weight of each rock, it will be a difficult task (without an exact measure like a scale, and the time and ability to move and weigh every rock).
Water Bottlecoffee_cup_003sky-on-rocks
Now if instead I ask you to tell me whether the previously mentioned coffee cup of water bottle is taller, that will likely be relatively easy for you to do.  In the same way if I ask you to group the pile of rocks as either small medium or large that should be relatively easy to do.  So "relative" estimating by comparing things is much easier to do than estimating by coming up with exact measures.  This is a key difference between traditional project / initiative budgeting and Agile budgeting.  In Agile we use a relative measure that is far less time consuming, but still good enough for a budget projection.  So using T-Shirt sizing takes advantage of the relative estimating approach in Agile and helps to identify a reasonable budget estimate for the work (while still maintaining flexibility / agility).  For the rest of how we apply T-Shirt sizing to Agile budgeting please see the video blog in my previous post "Budgeting for Agile Projects and Initiatives".
Thanks for reading, and until next time, Stay Agile!
John.

Saturday, 18 October 2014

Budgeting for Agile Projects and Initiatives


How do we budget for Agile Projects?  This Auspicious Agile (www.auspiciousagile.com) video blog entry talks about some techniques that can be used to plan and budget for Agile projects.


Please note that in the first video example the "most likely case" is only for concept demonstration purposes.  If we used the average velocity of the team (as 50 points per sprint) to calculate the most likely case it would actually take 5 sprints (for a backlog of 250 points) to complete.

Saturday, 6 September 2014

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.

Tuesday, 5 August 2014

Wednesday, 30 July 2014

The Best Agile Manager I Ever Worked For

As we continue to explore Agile leadership, today I want to talk about the best Agile Manager that I ever worked for.  It was several years ago, and I was working as part of a group that did custom software development projects for customers.  I started work on a new project that I had helped to kick-off several months before.  The project was for a US Government customer and the team manager was Jack (not his real name).

The team was made up of a business analyst, six or seven developers, and a development lead.  The team had recently started to use Agile methods, and was definitely in the midst of transitioning.  Jack was responsible for delivering the project for the US Government customer.  I joined the team in a senior developer and architect role.  The team needed to to develop a service integration capability quickly in order to fulfil the US Government requirements for the project.

What I liked about Jack's leadership style was that he empowered his team, he set vision for the team and looked to the members of the team to figure out how to get the job done.  Jack certainly fit the mould of a servant leader consistent with Agile principles.  This was a stark contrast, considering I had recently worked on a team with what I would consider to be the worst Agile Manager I had ever worked for (see archived blog post for that story), we will call him Bob.

To compare and contrast the other Manager that I had worked for previously was authoritarian.  No opinion was tolerated but his own.  His style of leadership was to create fear in the team.  Jack by contrast set vision and inspired the team to achieve its goals.  He did not use fear as a management tool, but rather he would seek to encourage the team, and to constantly find ways to remove roadblocks and impediments.

Jack was also trusted by the team.  When Jack asked a question or inquired into something, there was little question in your mind that he had good intentions and was looking to benefit you and the team.  By contrast when Bob (the fear based authoritarian manager) asked you a question, your heart would start to beat faster because you knew he was likely not asking for any good reason.  Rather he was generally seeking a way to accuse or belittle the team members, and most of his questions followed that pattern.

There was a prevailing good morale on Jack's team.  Even when we were up against a deadline or a challenge the team still worked together well and was positive.  Whenever we faced a challenge, the team was always engaged, focused and would "Fight On!" (the slogan selected by one of the team's developers).  By contrast on Bob's team everyone was just waiting for an opportunity to get off his team, and hoped they didn't make any mistakes that would get them in trouble.

Now notice that I did not focus here on how Jack did stand-ups, or how the team did retrospectives.  The team was learning, and did a decent job of putting these Agile rituals in place.  What made Jack a great Agile leader was not that he was able to follow Agile rituals.  What made Jack a great Agile leader was that he followed Agile principles in his leadership and the way that he treated his team.  This included respect for the team, openness, focus, simplicity, and trust.

Looking at the picture of Jack and contrasting with Bob who I described several blog posts ago, who would you rather work with as your manager?  When you think about who you would prefer, also think of the reasons why, is it based on following Agile practices, or is it based on the underlying Agile principles?  Food for thought...

Until next time, stay Agile,
John.


Saturday, 12 July 2014

Is making money the most important thing for an Agile team?

In the last few weeks in meetings in Malaysia and Singapore the topic of whether making money should be top priority for an Agile Team has come up.  For purposes of this discussion we will assume that the Agile team is a part of a larger business or organisation, and is not a stand-alone group.  So the larger question would be is making money the most important thing for the business or organisation that the Agile team is a part of.

From an Agile perspective we always focus on delivering value for the business or organisation (http://agilemanifesto.org/principles.html).  So let's define value.  In most cases if the business is a for-profit company or organisation value takes the form of producing better bottom line results.  This could be reducing costs, increasing revenue, increasing customer satisfaction, or improving employee morale in the company.  These may also apply to a non-profit organisation that seeks to break even, but not necessarily make a profit.  There are of course other areas where a team could deliver value, such as increasing market share, or improving company image.

So in order for an Agile team to deliver value to the business and organisation one of these areas should be improved by the team's work.  Now the question is which of these or other ways of delivering value to the organisation is most important.  Let's start with reducing costs, and proceed through the others.  If the team develops a productivity improvement that reduces costs for the company, then the organisation should be more profitable, and this will show as better bottom line results (i.e. company keeps more of the revenue it generates).  So reducing costs is directly related to making money.

Next we have increasing revenue.  This also is directly making more money for the company.  So work by the Agile team that increases revenue is also focused on the organisation making more money.  Increasing customer satisfaction means that likely more customers will use the organisations product or service.  Satisfied customers are happy spending their money on the company's products and services.  So customer satisfaction, while initially measured potentially by a survey or some other measure, in the end also results in the company making more money.

Now let's look at improving employee morale.  It can be said that if employee morale improves that happy employees will create better products and take pride and ownership in the work that they produce.  Now better products, and happy employees likely will lead to the company making more money, but it can be argued that improved employee morale does not always lead to the company making more money.  Happy employees also tend to be more likely to stay with the company, and attract others to the company.  This saves money for the company in its recruiting and related costs of finding and retaining talented people.  However, let's say for now that employee morale is not always measurable in bottom line results.

Increased market share, likely will result directly in the company making more money from more people buying its products or services.  An Agile team contributes to increased market share by creating great features and services that are valuable in the market place.  So again increased market share (in a well run company) should lead to the company making more money.  Lastly I mentioned improving company image.  This could take the form of better brand position in the market, or better brand recognition.  When more people know your company (hopefully for the right reasons) the company is again likely to make more money, through more people choosing to do business with the organisation.

Now, this is certainly not an exhaustive list of value producing activities in a company or organisation, but does touch on some of the most important for a for-profit company.  In addition there are non-profits, but most of these still apply, as a non-profit generally needs to break even to continue operating (this may take the form of attracting more money donations, which again would be value producing for the non-profit - take Wikipedia as an example).

So of our entire list just about every value producing activity for the Agile team ends up with the company or organisation making money.  Arguably we could say employee morale is not directly measurable in dollars and cents, but ties to money outcomes in many ways as well.  So if an Agile team is seeking to produce value for the organisation that it belongs to, it seems very likely that the value produced will have a financial or money measure.  This would point to making money for the organisation being the most important activity for an Agile team.

I would add to this one final point.  Even if an Agile team does not choose to focus on producing money for its organisation, the organisation will only be able to continue to operate as long as there are finances (money) to support the business as a going concern.  So if an Agile team does not support the monetary success of its organisation, the team may not be able to continue as a team if the organisation it belongs to is not profitable or at least able to break-even (in the case of a non-profit).

Until next time, keep thinking about Agility,
John.

Tuesday, 1 July 2014

Are there really no managers in Scrum?

Teaching classes over the past few weeks the question of what role managers have in Scrum has come up several times.  In answering these questions I mentioned that Scrum describes three primary roles - ScrumMaster, Product Owner, and Team.  However, Scrum is silent on the role of the manager.  I think this last point - the silence of Scrum on other roles - has led to much confusion, and maybe a few mis-steps by companies.

I can recall one company that was a client of a prior company where I started an Agile practice.  This US based company in the financial services sector laid-off (fired) all of their project managers in one fell swoop when they made the transition to Agile.  Now, I did not work directly with this company, and definitely would not recommend taking this approach to Agile Transformation.  I didn't keep track of what the outcome was of this mass lay off of project managers, but I can't imagine that it was good for morale in the company.

Scrum does not prescribe firing all of your project (or other managers) in order to transition to Scrum / Agile.  The origins of Scrum and Agile at the Team level in organisations has potentially led some people to think that there is no role for managers.  But to the contrary someone still has to deal with contracts, budgets, legal requirements, multi-team coordination, establishing communities of practice, and the like.  The likelihood is that a manager will be needed in some capacity to handle this in all but the smallest of projects / companies.  The other option would be for the team to stop their work on producing value during the sprint and instead to deal with all of these management tasks.  The second option is not conducive to a productive team that even comes close to burning down stories and tasks in "ideal time" or even close.

Another aspect to consider is that just getting rid of all of the managers in an organisation sows seeds of doubt in everyones mind (even if unspoken) about the value of people to the organisation.  Agile and Scrum do not support treating people as replaceable "resources" or cogs in the machine.  Indeed, Agile and Scrum support treating people as valuable individuals that contribute to the success of the organisation because they are empowered.  What does it say to people in the organisation when the leadership just fires everyone in the name of Agile Transformation.

I would propose that a better approach is to work with each person.  People who were business analysts or project managers or other roles not described in Scrum should be given the opportunity to identify career options in their organisation.  Maybe they can be ScrumMasters, or Product Owners.  Maybe they can be Agile Managers, taking care of the things that the team does not have time (and potentially skills) to handle.  The point for an Agile Manager is to be a servant leader empowering the team, and not getting in the way of the team doing work.  Business Analysts may be able to support Product owners in elaborating on User Stories, Assumption, and Acceptance Criteria.

I believe that the most respectful, and true to Agile / Scrum approach is to work with each team member and to help them to see where they fit in the organisation as the transition to Agile takes place.  This is best for teams, managers, and people, and Scrum / Agile always looks to empower and provide the best environment for people.

Until next time, keep being Agile!
John.


Monday, 16 June 2014

Small but not Lean or Agile

Several years ago I was working with a start-up company (we will call them Acme) in the technology space.  Start-up companies are known for being very Agile in their approach to the market, but that wasn't exactly the case with this start-up... The company was piloting a new on-line media technology that had significant potential to do very well in the market.  Similar technologies had just started to enter the market, but none with the same feature set as Acme.  Acme's founder (we will call him Fred) had worked very hard for a number of years to develop the technology and he had written most of the code himself.  Acme obtained preliminary intellectual property protection in the US.

Acme's founder Fred had a vision for his product entering the market.  He wanted to get a deal in place with a top tier Silicon Valley company or top Hollywood entertainment company.  Fred had several meetings that he hoped would lead to that one big deal that would make the company.  Unfortunately, none of these meetings ever materialised into the Holy Grail of a deal with a top company.

In the mean time many smaller opportunities to test Acme's product in the market came and went.  Now these opportunities wouldn't necessarily be make-or-break, but they would provide real world feedback, and potentially early revenue streams.  Ultimately Fred ran out of money before he could get Acme's product into the market.  The pursuit of a big deal that never materialised ultimately was the company's undoing.

Could there have been a different outcome using Agile and Lean Startup (http://theleanstartup.com/) principles?  I think so.  To start Fred could have attempted to test a Minimum Viable Product (MVP) in the market with a limited set of users to test Acme's concept.  This may have showed the potential of the product, or showed Fred where he needed to pivot and move in another direction.  This is a part of the core Build-Measure-Learn method that is core to the Lean Start-up approach.

Fred could have also started to realise revenue much more quickly than forever waiting for the one big deal that would make the company.  This was particularly important as Fred's company was bootstrapped and therefore had very limited funding.  Fred didn't have the cash to keep waiting for the elusive big deal while not deriving any revenue from the company.  When Fred realised (I am not sure this realisation came until he ran out of money) that the big companies he was pursuing weren't going to invest, he could have pivoted to seek smaller revenue streams from multiple early adopting customers.  Fred also had other opportunities like embedding Amazon products in his media technology, which would have potentially led to a stream of referral revenue from Amazon.

Fred spent a very long time working very hard on his product.  Adopting some Lean Start-up techniques could have potentially allowed his product and company to be successful.  Using a Build-Measure-Learn approach could have helped Fred to realise much needed revenue early, and to learn what worked in the market.  Having the flexibility to pivot when he saw the go big approach wasn't working could have made his company a success (in my opinion).  Also, finding an MVP that could earn revenue in the market could have provided much needed early cash flow.  All-in-all there were allot of potential benefits Fred could have realised using a Lean Start-up approach, instead of the "go big or go home" approach that he employed.

Until next time,
John.

Sunday, 8 June 2014

To Lead is Agile

Attending the Scrum Alliance Regional Scrum Gathering in Shanghai (www.scrumgathering.cn) this week the opening Key Note by Harvey Wheaton from Scrum Alliance addressed the role of leaders in Agile. Historically there has been the perception that managers and leaders do not have a role in an Agile team. Harvey's opening addressed some ways that leaders can be Agile.  I felt this was a very good opening to the conference as this is a topic that I am very passionate about.  I had many conversations with conference attendees, speakers, and business partners during the two days of the conference about the importance of leaders in Agile.

In both my own experience and that of many peers and colleagues I am aware of many Agile initiatives that never got off the ground because of a lack of leadership buy-in.  Ideally Scrum teams self-organize, but this often leaves managers and leaders feeling that they are left out.  The managers then often become reactive and in response oppose the Agile project or completely shut it down.

A better model is to include leaders in Agile plans up front.  To make key leaders in the organisation fans and sponsors of the Agile program.  After all there needs to be someone to champion the cause of the Agile team with upper management, someone to express the significant business value of an Agile approach.  A 2008 QSM Associates Agile Impact Report indicates Agile leads to 25% increased productivity, 50% faster time to market, 83% stakeholder satisfaction, and 49% less cost.

Managers are also needed to help Agile team members to build a career path in the company, to track against budgets, to address legal contracts with vendors, and to help coordinate across large programs that include many Agile teams. Managers for example can help to foster Communities of Practice where developers, testers, UX Designers and others can collaborate across the organisation and help to elevate Agile practices. 

When Agile teams and leaders collaborate the results can be exceptional and beautiful.  Software and products that are delivered to market quickly.  Business results in terms of more revenue for the company or organisation, happy teams, and servant leaders who grow to provide vision and support for their teams.  In this model everyone wins.  The key point for the Agile team here is that management and business leaders should be the Agile Team's best friends, and not perceived as the the enemy of the Agile Team.

Until next time, have a great weekend from Shanghai,
John.

Monday, 2 June 2014

Is it Okay to do Hybrid Agile?

In working with many companies, and talking with many of my colleagues (both Agilists, and non-Agile IT practitioners) the topic of Agile hybrids comes up frequently.  People ask whether it is okay to use Agile and waterfall side-by-side in the same organisation.  My answer to this comes in several parts.

First of all hybrids, while not ideal are a fact of life.  There are many companies that have transitioned their mobile projects for example to Agile, but legacy system projects are still done using a waterfall process.  Now, surely this is not ideal, it is much easier to adopt one methodology and stick with it consistently across an organisation.  However, not every organisation can adopt Agile in one fell swoop.  Instead it is sometimes necessary to move more slowly from traditional project management methods to Agile methods.

Second, there are some governance and regulatory requirements that companies are faced with, that in many cases require some traditional project methodology to be followed in the organisation.  This may be audit requirements for government, or process requirements in order to comply with the requirements of an industry standard.  This may also be a project lifecycle or method that is deeply ingrained in the company or organisation that will take time to change.  Whatever the case for the short term the organisation is forced to maintain some traditional project management process even while they transition to Agile.

Third, it is common for an organisation to see one of several scenarios internally that may cause them to deal with an Agile hybrid environment.  One scenario is where the company works with vendors who are using Agile methodology while the company is using traditional methods or vice-versa.  Another scenario is where different projects within the same program or group are using different methods (i.e. some are using Agile, and some are using waterfall or traditional methods).  A third scenario is where the organisation has chosen to define a process that is part traditional and part Agile (I don't suggest this unless it has really been well thought through, and there is a strong business driver not to fully change to an Agile approach).

Success Factors for working with a hybrid

So if you do find yourself dealing with an Agile hybrid in your organisation here are some things to keep in mind to make it successful.

1.  An Agile hybrid approach should be well though through, if it is haphazard and not well considered it is almost guaranteed to fail.  One example of an organisation that had thought through this well was a multi-national entertainment company I worked with.  Their PMO had defined a methodology that allowed for a constant project discovery and initiation phase, and then allowed each project to select either iterative (Agile) or traditional project execution (design - build - test).  The projects were then deployed and closed using traditional methodology.  Again while this is not ideal (Water-Scrum-Fall) it was well thought through, and to some degree was working for the organisation, though I believe they were still in the process of changing their project approach, and this was not the end-point.

2.  Identify what type of hybrid you are dealing with.  Is it a hybrid group or program, a hybrid due to an Agile vendor, or an intentionally hybrid internal process?  Your organisation should decide whether this hybrid is the end point, or if it is somewhere along the course of an Agile transformation journey.  Maybe you are only operating in this hybrid fashion until you can move your legacy teams to a Kanban based approach, or until it is politically viable to transition fully to Agile (yes ensuring a politically viable transition with minimal resistance is a valid reason to use a hybrid approach for a period of time before a full Agile transition can be completed).

3.  If you have operational projects that use a traditional methodology, or on-going project maintenance that uses an existing process consider using a Kanban approach.  A Kanban approach using continuous flow and Work in Process (WIP) limits can allow all of your projects to take an Agile / Lean approach while still using some of your existing processes that may be needed for regulatory compliance or other considerations.

What is really key is to decide whether a hybrid is an end in itself, or if is only a means to an end (i.e. becoming more / fully Agile).  I think there can be a valid case for using a hybrid for a period of time, but I believe that ideally it is best to use a hybrid approach as a vehicle to make your organisation more Agile.  A hybrid is best used when it is a tool that helps your organisation to move forward in its Agile journey.  I hope some of these considerations will help you as you think through using a hybrid approach in your organisation (or not).

Until next time,
John.

Monday, 26 May 2014

The Worst Agile Boss I Ever Worked For

So as we continue to look at Agile Leadership and what makes a great Agile leader, I would like to talk about the worst Agile boss I ever worked for.  Several years ago I worked for a company in a group that was responsible for custom software development and custom interfaces.  Two of the original leaders of the group had left, one to another division in the company and another to start a new venture.  The manager that remained (we will call him Bob) was very power hungry and led the team by fear.

Now the VP in charge of our group indicated that he would like for the teams in our group use an Agile approach for software development.  This Agile approach came in the form of adoption of an Agile tool, and doing daily stand-up meetings with the teams.  So Bob decided to start doing daily stand-ups with our team.  Bob would have us sit down in a meeting room first thing in the morning (~8am) and interrogate us about what work we had done.  If he was not satisfied with the answer he would prod and question and demand the answer he wanted about the work.  I imagine Bob would have considered himself to be the ScrumMaster.  However, this was far from the servant leadership / coach role that a ScumMaster is supposed to play.

I remember in one particular "Stand-up" with Bob, he interrogated and questioned one of my team mates to the point that he was in tears.  I can honestly say that in all my working career this was the only time (and still is) that I have seen a grown man break down in tears in a meeting at the office.  Bob seemed to get great satisfaction in intimidating team members and having unquestioning adherence to his program.  Unfortunately nothing about Bob's approach was Agile.  An Agile leader serves their team, not intimidating them and leading by fear.  An Agile leader empowers their team, and helps them to do their best work, and to self-organise.  Bob did none of these things.

An Agile leader provides vision that the team can work towards and be inspired by.  Bob provided no vision, and in one meeting when asked what the vision was for the team, his only answer was awkward silence.  Bob was actually threatened by his team members doing well, and wanted to make sure no one rose above him, so he used fear and intimidation.  An Agile leader looks to bring out the best in their team, and by doing so brings out the best in themselves.  Indeed Bob was an objet lesson in how NOT to be an Agile Leader, whether ScrumMaster, Product Owner, Agile Manager, or executive!

If there is any key lesson here for me it would be:  As an Agile leader don't be like BOB!  In fact when I think back on my time working on Bob's team it helps me to be very clear what I NEVER want to do to my team or others as a leader!

Until next time,
John.

Thursday, 22 May 2014

Why Should I use a Framework to Scale Agile?

In my career and that of many Agile coaches and consultants that I have worked with scaling of Agile to the Enterprise level has come up while working with customers and companies.  The idea of scaling Agile is not new, but approaches to do this are quite honestly not very mature.  This question is frequently on the minds of IT and business leaders that I have worked with from Software VPs, to CIOs, VPs of PMO to business executives.  They hear about the benefits of Agile, maybe in an industry publication, or from a colleague or peer in industry.  But then the concern turns to how (and if) Agile can work in their enterprise, with hundreds or thousands of people and multiple locations (often in different countries and time zones).

Agile is well defined at a team level, Scrum, Kanban, and XP as well as other variants have been around for a long time, and there are many trained and skilled practitioners.  However, when it comes time to scale to say a company with development teams in the US, Asia, and Europe things become a little more unclear.  We can use Scrum-of-Scrums to scale up to handle multiple teams.  In terms of running the necessary programs, budgets, contracts, and team coordination there are allot of questions that generally are not prescribed by simply scaling using a Scrum-of-Scrums approach.  The team then enters uncharted territory for team level Agile.

In some smaller organisations that already use Lean Startup and related Agile practices this may not cause too much of a problem.  However for a large Financial Services, Entertainment, or Manufacturing multi-national this is much more of an issue.  How do they track the progress of multiple Agile teams?  How do they ensure that the budgets allocated by the executive team are being  well spent?  How do they have teams in multiple time zones 12 hours apart, or 8 hours apart work together in a stand-up?  The questions go on and on...

Basically in my experience enterprises end up making up an approach as they go along, a "home made" approach to scaling Agile.  While this is a road that enterprises can and do choose to go, it is not necessarily the best one.  I have been part of teams that have done this and it is quite stressful for the teams and the leaders, making it up as they go along.  I am sure this has caused many managers and execs quite a few sleepless nights worrying about what to do next, and if they will succeed at all.

Having recently spent time looking at several pre-defined approaches for enterprise Agile, such as DAD (http://disciplinedagiledelivery.wordpress.com/introduction-to-dad/), Agile Path (http://www.ebmgt.org/Agility-Path-Framework), SAFe (http://scaledagileframework.com/), LeSS, Spotify, and several others I think that in many cases it is a better approach for an enterprise to adopt or adapt an Enterprise Agile Framework rather than making up their own.  There are several reasons: First it saves companies time, second it allows managers and leaders to find something proven that other companies have used, and third enterprises can reference other companies, case studies, and practitioners for guidance.

Of the frameworks I have been impressed with SAFe as it matches allot of what I have seen when large companies have created functioning approaches to scaling Agile (for instance the Team, Program, and portfolio distinction within SAFe matches what I have seen in large enterprises).  I also like that there are many references to companies that are already using the framework, and there is a path to certification which I think is useful for enterprises.

In fairness, I have spent more time working with SAFe recently than any of the other Agile Scaling Frameworks.  Also, I do not think that any of these frameworks fully defines every step that a company will need to take to implement a Scaled Agile Program (though SAFe does admit that not every aspect of implementation is covered - http://www.scaledagileframework.com/implementing/).  Finally SAFe is still relatively new, though the concepts underlying it have been around for a while.

However, from what I have experienced along with my discussions with other Agile practitioners, it is my opinion that Enterprises are better off to start with a framework for scaling Agile (whether SAFe or another framework), than to go it alone and make up their own.  The key is to make sure that the Enterprise Agile Scaling framework you choose is implementable in your particular business context and matches up with the way that you do business (more on this in future posts).

All the best, from Singapore,
John.

**Note:  My latest series on comparing Agile Scaling Frameworks here (LESS vis-a-vis SAFE) may be of interest to readers of this post.

Friday, 16 May 2014

The Director that loved to shuffle his Agile Team

At a multi-national entertainment company that had adopted Agile at a large scale ($1 billion USD program, with ~500 developers plus shared services teams) I worked with the Director of a group that was adopting Agile.  The Director was a huge proponent of Agile which really helped with adoption within the team.  Our team actually used a Kanban variant (actually "Scrumban" aligned with the cadence of the other team's on the project which used Scrum - why we chose a Kanban variant is a story for another time) to deliver.  From an Agile practices perspective the team and the organisation overall were becoming quite mature.

However, this is not an Agile process story, but rather a story about Agile leadership and people.  You see even though this Director (we will call him Ed) was a great supporter of Agile within his team and his group he had one leadership habit that often sabotaged our efforts.  Ed loved to switch his team members from project to project.  He would spend the day "wheeling and dealing" with the other managers, Directors, and VPs at the company about who would work on what project.  I think this was one of his greatest joys.

In one example of how this affected the team, Ed  came merrily into the office one morning as our team was headed toward an important delivery milestone.  Different aspects of the included stories had been in-progress for some time in the continuous flow and we were nearing completion.  Ed then decided that day that he would move a key team member (we will call her Mary) who had been dedicated to this particular project.  Mary came to let me know that she was being moved to another project, which I immediately checked with Ed.  He confirmed that he had other "Important Work" that he needed Mary to do, and someone else would need to to backfill for Mary.

Now Ed and I were both aware that using an Agile approach whether Scrum, Kanban, or "Scrumban" it is not desirable to move team members frequently, and especially not mid-sprint / mid-strory.  The features based on the stories that Mary had been working on languished, as no one had the background that she did to ensure completion.  Mary also seemed very demoralised at being removed from the project and team at such a key point just before we could finally deliver.

Subsequently about one to two months later Mary left the company to pursue another opportunity.  While she never told me if this was in part due to being moved from project to project like a "cog-in-the-system", I suspect that this was a large part of her decision to leave.  Mary had shared with the team that she had been on the fence about leaving for some time.  It is likely that the demoralising move and not being treated as a person, but rather a "resource" to be shuffled on a whim contributed to her decision.  The Agile moral of the the story is that in Agile leaders need to have the respect for team members and teams to let them complete their work, and to treat team members as people instead of replaceable "resources".

Signing off from Singapore.
John.

Wednesday, 14 May 2014

The company where Agile was a "Four letter word"

In my prior experience at the US offices of an Asian car manufacturer (we'll call them Acme):  My consulting company was developing the opportunity to do a new project with Acme.  I had newly started the Agile practice and was keen to identify initial customers.

We started meetings with the auto financing group of the Acme to discuss the project. The leaders of the Acme Project Management Office (PMO) seemed to want to know all about Agile methods.  After several meetings (and many questions about Agile) it seemed everything was lining up well.  

After talking informally with a few friends and colleagues though I became a little concerned.  It seemed this division of the company (and it's PMO) actually had a reputation for being very anti-Agile.  Sure enough the people who had seemed very interested in Agile during our prior discussions soon indicated that they did not want to use Agile methods at all!

The project did go forward, but without the involvement of our Agile services group.  After analyzing the situation in retrospect I realized that the financing group had almost no exposure to outside market pressures.  Because of this they had no concern about getting to market quickly or satisfying their customer.  Their customer was the auto manufacturing division - and their customer wasn't going to switch to another finance company! 

This led to a key learning for me:  Companies (or divisions) that have little exposure to market pressures have almost no motivation to be Agile.  Instead, in some cases an anti-Agile "status-quo" mentality dominates.  An important consideration before starting down the road of Agile with a company - Are they really concerned about the market at all?  

I am interested if others have seen similar scenarios, where a company / division had no interest in Agile because they had very little direct exposure to the market?  Maybe a captive finance company, government contractor, or other protected company with high barriers to entry.  Maybe a company you work for now ...

Signing off from Bangkok.  John.

Sunday, 11 May 2014

Welcome to Auspicious Agile

Auspicious Agile is all about using Agile successfully in the Enterprise, in business, as a leader and adapting Agile methods for Asia.  So first a little background on me:  My name is John Okoro, I have worked in the technology and consulting space for nearly two decades, and have used Agile methods for roughly seven years.  I started my career working for a Big 6 consultancy (now Big 4) and have seen a wide range of projects in numerous industries.  Throughout my career I have been responsible for leading projects and teams.  In this blog I hope to bring insights that I have developed throughout my career, as well as valuable insights from the many colleagues and peers I have worked with along the way.

Agile as discussed here refers to the combined group of methods that derive from the Agile Manifesto (http://agilemanifesto.org), Lean principles, and related methods.  These include but are not limited to:  Scrum, Kanban, XP, and SAFe.  One consistent theme that I have encountered with these and other Agile methods is the need for an approach to leverage Agile at all levels of the Enterprise (from teams up to executives).  The need for Agile leadership principles that align with the use of Agile methods (Servant Leadership, empowering teams, vision casting), and Agile business methods (Lean Start-up, Design Thinking) are also quite consistent.

Finally, Agile methods in Asia call for additional consideration in applying to different cultural contexts from those found in the US and the West.  There is often more hierarchy, and the pronounced need to approach Agile from both a Leadership and Team level to be successful.  Enterprises, in particular in China are often much larger with technology groups numbering in thousands instead of hundreds as is frequently seen in the West.  I hope to address these nuances and promote a fun and lively discussion on these topics as well.

I look forward to highlighting stories, cases, and insights each week that will help each Agile practitioner, agilist, and participant in this conversation to practice Auspicious Agile.  Have a great week ahead.  John.