Criteria for a First Agile Project

I like to say that the best time to adopt agile in a large company or an enterprise is when there are the right business conditions. This may seem odd for a software development process, but while the development team has a lot to master when it comes to agile, it's the business functions that exhibit the most changes and must also put a lot of trust in their technology colleagues.

I speak this from some experience. When I joined BusinessWeek almost three years ago, it was with incredible support to get an agile development process going in order to launch Business Exchange. It was well understood that Agile's frequent release schedule, its process for leveraging user feedback to reset priorities, and its culture of simplifying requirements to the must-have are all key to consumer products.


Criteria for a First Agile Project

So for a first agile project, here are several important criteria that I consider:

  • Business - Ideally, a single business sponsor for an important project with a well articulated vision but undefined requirements. Also ideal is a good working relationship between this business sponsor and the lead technologists.
  • Product - Ideally, the product manager should be able to directly engage customers on a regular basis. I think that new teams will have an easier time working on a new product or functionality rather than a legacy product. (More on legacy projects and agile in another post!) Also, for a first agile project, it is a lot less risk working on a product that can be rolled out to customers incrementally rather than products that have scale at roll out.
  • Project Management - Ideally, I'm looking for projects that are 4-6 months in length that can be worked on with one or two teams.
  • Technology - I consider several criteria covering agile experience, maturity of the technology platform, whether the project requires new technologies and/or significant integration efforts, and the maturity of the QA practice. 
Now any agile coach looking at this list will say, "great job Isaac, now let's talk about the real world". In other words, you'll rarely see the ideal criteria. The important thing to recognize from this list is how to de-risk a project based on the working conditions.  That being said, in practice, it is easier to compensate for less ideal conditions in the project and technology areas than the business or product ones.

Here's a more simple set of conditions; if you can get a business lead and a tech lead working together and committed to the agile methodology; if you can staff a cross discipline team to work together on the project, if you can get at least one person on the team with strong agile experience, if you can get some basic development environments, if you can write down a few things to work on first and commit to getting them completed in a fixed and short amount of time - you've just kicked off your first agile project.
continue reading "Criteria for a First Agile Project"

Four Phases of Maturing Enterprise Agile Development

Are you a technology executive looking to adopt or migrate to an agile software development practice? According to a Forrester survey Mainstream Adoption Has Changed Agility, 35% of IT professionals say their development practice most closely resembles an agile development practice causing the media proclamation that agile is now mainstream. But of course this also means that 65% are not practicing agile and I'm certain that a large number of the 35% are only just maturing their practice.

My last post covered the role of the CIO in adopting agile where I gave some important tips with links to some other posts covering organizational issues. In this post, I'd like to share some concepts on maturing the agile software development lifecycle. Note that this is not a maturity model, as I've stated previously Agile Does Not Need A Maturity Model and on maturing agile without a model. The concepts below highlight the progression of adopting agile without going into a specific model, measurement, or approach.

Agile Maturity Comes in Four Overlapping Phases

Unlike other approaches to mature a practice , I believe agile practices mature in phases that overlap. Let me first describe them:

  • Pilot project(s) - Agile is best started by selecting an appropriate project, getting a few things in order prior to project start, and then diving in. If you have little agile experience, get a coach and seek out some training for team members. Make sure the business project is appropriate (I will cover in a future post) and make sure its sponsors are willing to participate in the program. Then follow a guide for starting agile. Your coach will probably have a program, but here's one on How to Implement Scrum in 10 Easy Steps. Also, see my Top Ten Thoughts for SCRUM Newbies. (Can't believe I wrote this almost a year ago!). Also, I wrote on the Top Seven Ingredients to Establishing an Agile Develpment Practice.

  • Establish the SDLC - As you're team completes iterations successfully, the team's practices will begin to gel into a process. It's at this point, you'll want to decide what aspects to formalize and what it means to formalize them. How long is the iteration? How are stories conceptualized, written, reviewed, sized, and prioritized? What meetings are needed, when should they be scheduled and who should be invited? When should the build close, how should final testing be conducted, and when should it be deployed? These are just a few of the questions that should be debated and structured during the pilot project, then reviewed and upgraded as the process matures.

  • Rebuild the Business / IT Working Relationship - Shocked that I haven't really covered this in previous post, so here's my commitment to cover this one. One big area is understanding the roles/responsibilities of the product manager (which many businesses have and are part strategic, part tactical) and the product owner (an agile role that is tactical and requiring both business and technical skills). This series on the Agile Product Manager has many good insights and tips. Second, the agile practice requires active business participation in each iteration to review and prioritize new stories and to sign off on completed ones. So in short, agile forces a different business process for developing new products and enhancements, so expect to work these changes in as the Development Team matures its practice.

  • Scaling the practice -  At some point, you'll be thinking, "Ok, I have this working with one team and one product, now how to make this work with multiple teams? product lines? multiple businesses?" Will you make all projects follow an agile practice, or will you set guidelines on when to use agile vs. other practices? You might wrestle with what practices to standardize, how to set principles around self organization, and how to retain and hire talent into the practice.  How will you roll out tools that multiple teams can utilize in semi-uniform way? What metrics will you utilize? Solving many of these concerns essentially help determine how the practice will live on beyond project and team #1.
 Looking at these four phases, and you should be able to visualize the overlaps:
  • Start with the pilot project
  • Approximately 30-40% into the pilot project, begin work on the SDLC and the Business / IT relationship - ideally simultaneously.
  • Once you have a working SDLC and new working practice with the Business, start thinking about how you will scale it. Ideally, the complexities in scaling the practice should be addressed by both the business / IT working relationship and and technical process (aka, the agile sdlc).
  • Revisit and mature all practices as new teams take on the process.
Obviously, this is somewhat conceptual (it is a blog post....), but hopefully this will help you get past some fears from taking the first steps.
continue reading "Four Phases of Maturing Enterprise Agile Development"

Adopting Agile Development - The role of the CIO

I've been covering the CIO path to credibility. First, the CIO must be able to negotiate priorities and develop a path for consistent delivery - which is why I thing the CIO loves Agile (or should love it). So if you are buying into my methodology, the next step the CIO must determine is how to introduce an agile development life cycle to both the Technology and the Business organizations.

Now my assumption is that if you're reading this blog or post, you know a fair amount about agile development and planning. So I'm going to stay specific to the role of the CIO and responsibilities you must take on.

1) Sell it - The key question - how will the organization benefit from shifting to agile? Expect to get lots of questions. How will it affect business priorities? How will resources be trained? How long and expensive is this shift? The CIO has to anticipate these questions and work with his leadership team to plan the transition and be prepared to answer these types of questions.

2) Identify executive business sponsors - First, migrating to agile is a lot easier if you have a strong business executive sponsor. If you don't have that yet, you'll have a harder time selling and proving the benefits, but that shouldn't discourage you from taking on the challenge. Make sure that you keep executive sponsors (or possible ones) updated on the team's successes and how you're overcoming challenges. Invite them to demos even if they can't come. Here are some of my thoughts on getting Executives to buy into agile.

3) Identify the initial project(s) - I don't believe in shifting multi-team organizations to agile in one shot. Most agile coaches will tell you that the agile process needs to be adapted to the organizational dynamics and business needs. For that reason, it's best to select one, maybe two projects, get agile working, then look to scale a process to to other teams. What makes a good agile project? A good option is to find a business important project that has no/few requirements (early inception stage), will require several months of effort from one or only a few teams, and is most likely to benefit from an iterative delivery cycle.

4) Help the project sponsors - Shifting to agile can also be a major change for business sponsors. You have to sort out how to fill the product owner role (see: Agile Product Owners in the Enterprise). Sponsors have to learn how to work priorities, requirements and scope changes in this product life cycle and IT leadership have to help Sponsors learn their responsibilities. See my posts on Business Responsibilities working with Agile Teams Part 1 and Part 2.

5) Help the team make it successful - Make sure all team members have a basic foundation in an agile (probably scrum) process. I highly recommend training and ideally an agile coach if you can afford it, but at minimum make sure you have a team lead (scrum master...) who's been through a successful agile project. Make sure the team has a basic process in place even for iteration #1 and attend a few stand ups to help with the blocks and other issues that arise. Help individuals understand their role in the process and identify skill set gaps.


6) Find and manage the skeptics - Assume that you'll have skeptics with any process change and even the possibility of saboteurs. Look for the signs and help manage these situations.

7) Define self organization - This is a key tenet of agile, yet there are boundaries in organizations defined by policy and practice. Policy might define financial boundaries, rules on how technology is selected, change management practices, etc. Also, talented teams can easily extend self organizing principles and attempt to take on the responsibilities of other teams. 

8) Don't leave out QA - The QA team has to redefine itself quite a bit when Development teams move to agile. There are some folks in the agile community that believe the QA function is replaces by agile's short/iterative delivery cycle and with the maturity/adoption of unit testing frame works. I'm not one of these people. I'll have another post on this subject but to keep things simple for now, the CIO should get active to make sure that QA responsibilities and resources fit into the organization's agile process and methodology.

What did I leave out? I might need a part 2 to this post...

continue reading "Adopting Agile Development - The role of the CIO"
Share

About Isaac Sacolick

Isaac Sacolick is President of StarCIO, a technology leadership company that guides organizations on building digital transformation core competencies. He is the author of Digital Trailblazer and the Amazon bestseller Driving Digital and speaks about agile planning, devops, data science, product management, and other digital transformation best practices. Sacolick is a recognized top social CIO, a digital transformation influencer, and has over 900 articles published at InfoWorld, CIO.com, his blog Social, Agile, and Transformation, and other sites. You can find him sharing new insights @NYIke on Twitter, his Driving Digital Standup YouTube channel, or during the Coffee with Digital Trailblazers.