10 Tips for Agile Adoption in the Enterprise

[This article is a guest post by Rajesh Raheja, who is a senior director of development in the Oracle Fusion Middleware SOA group. He is a Certified ScrumMaster and a Stanford Certified Project Manager. You can visit his blog or connect on Twitter @RahejaRajesh. Note: The views expressed on this blog are his personal views and do not necessarily reflect the views of his employer.]

A few months back I wrote about the challenges facing agile adoption in the enterprise. It stressed on the three areas: complex interdependencies across projects, effective utilization of specialized, shared resources across projects, and finally, the “sprint overhead” for complex, architectural tasks.

In this post, I would like to outline a few tips to overcome some of these challenges.

1. Get management buy-in. Program Managers should be aware of the agile approach, usage and expectations. If they are not on board, any additional work to convert reporting from agile to waterfall style adds no value.

2. Plan for entire releases, not just one sprint. Use story points to estimate and extrapolate velocity from one sprint to future sprints. A lot of project planning is based on the project manager and team’s experience in estimating work; and this does not reduce with agile planning. Note that the future sprints don’t need to be fully nailed down at the start itself (that would defeat the agile purpose), hence the use of extrapolation. Some agile tools support this concept by allowing the placement of backlog items on specific releases.

3. Plan sprints with specialized/shared resources in mind. For example, plan on effective usage of an architect or a performance expert’s time. Don’t expect these resources to be part of your sprint / daily stand ups.

4. Complex inter-dependencies are a reality – deal with it! Identify dependencies across project modules/components upfront during release planning. In some cases, we called this a special sprint called “Sprint Zero.” Use this sprint to also get commitments from dependent teams so that you can use this to plan future sprints. Use this sprint to also design the overall architectural requirements, so that these are not limited by the “sprint overhead.”

5. Keep reasonable sprint lengths – at 3 or 4 weeks. Integration flows and services are complex and shortening the sprint length to 2 weeks makes it impractical to complete any full-fledged integration flow. Keep sprints lengths at 3-4 weeks so that either a complete service or integration flow can be developed and tested. Specifically, Sprint Zero may be the largest sprint of the project so as to remove sprint overhead on the rest of the sprints.

6. Don’t expect all sprint deliverables to be production ready. Especially in enterprise integration projects that have very complex dependencies across legacy applications, the initial sprints build the foundation for the end-to-end integration flows. Latter sprints can then execute deliverables from all dependencies and test the overall integration flow.

7. Define “done” consistently across the teams. For example, “done” could imply the following: design, coding, unit testing and coding deploy scripts. Further more you may want to include the specification of system tests (as opposed to execution) to be part of the story in case service dependencies restrict system testing.

8. Reserve at least two “hardening” sprints. Use these sprints purely for bug hunts, system testing and refining any remaining packaging/deployment tasks.

9. Be pragmatic about usable documentation. Use an agile design document template or use Wiki’s instead of writing reams of documentation that no one will probably read. On the other hand, don’t skimp documentation only in favor of code comments because you need to document the functional context and know-how to benefit future developers.

10. Adopt continuous integration principles. Build early, build often, and don’t break the build. This is invaluable for complex code interdependencies.

The following diagram highlights some of the above principles used within many of our integration development projects.

A special Sprint Zero is followed by iterations of functional and design specifications for the overall business process flow or architecture design. The output flows into Construct sprints, which goes into Test sprints. While at the outset this may look like waterfall-ish, this “iterfall” approach worked very well in combining the best of both worlds, reducing project risk and increasing visibility into the project details. The above concepts would also work well with other agile methodologies as well such as Kanban, which introduces a process oriented workflow in place of time-boxed sprints.

[Want to guest post? Let us know]

24 Replies to “10 Tips for Agile Adoption in the Enterprise”

  1. Dude… analysis sprints, followed by design sprints, followed by construction sprints, followed by testing sprints!? I think you need to elaborate this thinking for us a bit…. I do enterprise agile every day without those constructs. Why would you feel the need for this?

    1. Mike, good points on the last paragraph. Would like to see what Rajesh has to say about it.

      Thats why AgileScout is here. We provide opportunity for authors/contributors to bring their ideas to a wider audience!

      Thanks for chiming in Mike 🙂

    2. Yeah, another sad example of a project manager’s approach to “Agile”. Even the useful suggestions in this post (and there are some) come across as prescriptive. I wish people would realise there is no step-by-step guide to creating innovative products. If you want prescription go work on an assembly line.

      1. Tobias. I seriously love your candidness about everything!
        Prescriptions for processes are as outdated as the early manufacturing processes.
        Prescriptions for processes work perfectly in an input-output system. Zero variation.
        Software development is all variation, right? 🙂

      2. Tobias,

        I agree that prescription does not work with innovative product development. As I clarified to Mike above, these are tips that I found useful in working with very large cross-enterprise application integration projects, where frankly agile still faces challenges (see my earlier earlier post). For all other use cases, standard Scrum processes with 2-week sprint times and no Sprint Zeros have worked just fine.

        Having said that, what I consider sad is that the essence of “Agile” is getting lost in favor of almost cult-like fervor in the rigidity of Scrum.

        Instead of adhering to the agile manifesto and focusing on “uncovering better ways of developing software by doing it and helping others do it”, those same ways are shot down Scrum purists who insist on rigid methods. Doesn’t that just go against what agile stands for?

        I liked your blog post on “Do Marriages Fail”, where you strongly argue it does not; the idea is sound but implementations may fail. I totally agree, but when it does work, it still requires compromises between the two partners. Similarly, Scrum is a very sound idea, but its implementations MAY require some tweaking. These compromises – as in marraiges – are real. In one of your blog posts, you lament the association of agile to project management and suggest not to tone it down, but it’s ironic that in yet another post you suggested using the term “conversation” instead of “meetings” to do the same.

        The agile manifesto values “Individuals and interactions over processes and tools; Working software over comprehensive documentation; Customer collaboration over contract negotiation and Responding to change over following a plan”. All the above tips were collated by many extremely bright individual developers, who found this useful to create working software, by collaborating with customers. Why not value those individuals finding ways to better the software development process, instead of sticking to rigid Scrum processes?

        Finally, on the topic of project management vs agile, having actually developed many enterprise products throughout their lifecycle from concept, strategy, architecture, development, testing, product mangement, marketing, launch, training, support and even obsolescence, I find it a very myopic view to discard the value of overall project management to an organization.


        1. Hi Rajesh. I think you misunderstand the intent of my post.

          > cult-like fervor in the rigidity of Scrum… shot down Scrum purists who insist on rigid methods…
          I wouldn’t know about that as I am not a Scrum purist (whatever that is). I use the lightweight framework of Scrum as a starting point to help organizations reveal and (perhaps) address their dysfunction. I use the principles and values that underlie Scrum to create an environment of continuous improvement. If this isn’t Agile, I’m okay with that. I am not especially bought into Agile.

          > Scrum is a very sound idea, but its implementations MAY require some tweaking.
          Its implementations are almost all tweaking. Scrum is non-prescriptive except for the bare fundamentals (which I wrote about here: http://bit.ly/OGcVE). If you don’t find a way to forge a process suited to your context, and don’t add some actual work practices you won’t get anything done.

          My interest is not in seeking ways to compromise, but rather seeking to confront and challenge, to push people and organizations towards their edge. Using new language (e.g. conversation instead of meeting) is one step in that direction, it is not, as you suggest, a way of “toning it down”. A conversation is riskier than a meeting. It requires that we look into each others eyes and engage in truthful dialog. It is not about following an agenda. Scrum takes people out of their comfort zone. What I see in the typical project manager approach to Agile is a way to be safe. While that may get your mammoth enterprise applications out of the door, it doesn’t actually change very much. I suspect the world is the same place it was before you began. Or perhaps it is a world with one more enterprise application.

          > I find it a very myopic view to discard the value of overall project management
          Funny, I find it myopic to hold onto that 🙂 I reckon it blocks our vision of all the other unseen possibilities.

          I am not trying to criticize you or your work. I get that you have done good things, and are offering some tips (not prescription as I originally accused you of) to others who may be in your position. This is all good. And there is much, much more to be done. I just caution you—and everyone—to look beyond compromise and find a way to reconceive the way we show up for work.

          1. Hi Tobias – thanks for taking the time to reply to the comment.

            btw, my comment on Scrum “purists” was not directed at you; I had originally referred to it in my first post given my prior experiences.

            Let’s agree to disagree on whether overall project management adds any value, but it is good to know that we are on the same page regarding the intent of Scrum – radically changing the way we work – but using different means to achieve the same goal.


        2. Rajesh — thanks for being a voice for those of us who have to work on large, complex projects. Scrum is great for what I call the “agile assembly line” but it doesn’t cover the framework needed for the efficient running of an Agile Software Factory; a factory whose output must be fairly predictable in spite of fixed yearly budgets and demanding product roadmaps. I’m one of those individuals who had to figure out a way to blend Scrum with a project management framework that would enable my team to pursue value and yet meet the demands of our business. I wrote a book about my methods and have shared my mgmt templates online at no cost (agiledevpointing.com). As for your Agile Tips List, we’re doing 100% of what’s on your list; GREAT JOB. Best of luck to all project managers out there who have challenging projects and yet are still determined to leverage agile! Peggy S. Morgan

    3. Mike, I guess I should have clarified that most of the tips related to the challenges faced in the related blog post http://agilescout.wpengine.com/agile-adoption-challenges-in-the-enterprise-applications/ in developing enterprise application integration projects. These types of projects (e.g. Order to Cash) are some of the costliest areas in enterprise implementations for a good reason – their complexity due to integrations across multiple divisions in the enterprise (very often even acquired companies), across multiple geographies, multiple shared resources etc.

      Given the end-goal of end-to-end business flows, it made sense to break down stories by integration services and then combining them in integration flows. Commitment challenges across various divisions created the need for Sprint Zero. Production readiness for such services can only be attested by a thorough end-to-end testing of various use cases across the enterprise systems, which led to the hardening sprints. You can find the scope and more details about these kinds of projects I referred to at http://www.oracle.com/us/products/applications/application-integration-architecture/054280.html

      Could this have been done in a different manner? Why, absolutely yes. I would love to hear in the comments suggestions from folks who have done enterprise application integrations (on premise or across SaaS based applications) without resorting to artificial breakdown of work that may only satisfy Scrum purists, but eventually not meet the business goals.

      1. Rajesh…

        There are two lines of the manifesto that are pivotal here…

        Working Software OVER Comprehensive Documentation
        Responding to Change OVER Following a Plan

        I hear you when you talk about establishing teams around services and having to manage the flow of value across services. That is the key problem to solve in complex enterprise agile projects. That DOES NOT mean that you have to have a waterfall plan delivered in two week increments.

        How does your approach create working software early? How does your plan give the business the ability to change direction? How do you insert new work into the queue when business needs change? How do you constantly keep the product potentially shippable? How do you pay attention to empowerment and self-organization in this model?

        I have used your approach as a TRANSITION PATTERN for an organization unable to adopt agile right out the gate… I think it can work… I don’t think it is agile… i don’t think it is enterprise agile. That is why you are getting this reaction from me, I think it is harmful to say this is enterprise agile.

        Rather than Agile/Waterfall as a scaling pattern, i would rather see an agile/lean/kanban/TOC/RUP scaling pattern. I video blogged on this a bit and will be speaking on it at SFAgile2011 and Agile2011.


        The goal of enterprise agile is not to force fit two-week planning cycles and daily standup meetings into a waterfall process. The goal is to be able to give the enterprise the ability to inspect and adapt and respond to change and deal with complex systems. This is not a matter of being a Scrum purist… it’s a matter of asking the question how your approach gives me BUSINESS AGILITY. I don’t think it does.

        I am sincerely interested to hear how you created business agility with this approach.


        1. Hi Mike, thanks for your feedback. I went through your video and pattern we used was very close to your Tier 2. Although we did not use Kanban, the work in progress categories were similar – Analysis, Build, Integration Test, System Test; which is why I said that it seemed like waterfall. In fact my first reaction on seeing Tier 2 was “that’s just waterfall” until you started explaining it – which is the exact same reaction I got from you 🙂

          Let me explain our approach and I would like your feedback on how it could be improved.

          Enterprise application integrations are all about end-to-end business process flows, each containing multiple integration flows. In the waterfall approach, the entire business process was analyzed, then fully built and only then tested. Timeline to develop enterprise integrations were around 9-15 months with almost 3-6 months spent in analysis of cross-application mappings.

          With our agile approach, the end-product is broken down into a set of integration flows (features) with user stories being the underlying services that make up the flow, for example:

          F1: Integration Flow (Sync Order between CRM and ERP system for Fulfillment)

          F1-S1 Mapping between CRM and ERP System for CRM Sales Order to ERP Fulfillment Order
          F1-S2 Create or enhance CRM web services…done by CRM team; could be different company as well (depends on F1-S1 to start)
          F1-S3 Create of enhance ERP web services…done by CRM team; could be different company as well (depends on F1-S1 to start)
          F1-S4 Connector to be developed for CRM system using decided upon mapping (depends on F1-S2 to start)
          F1-S5 Connector to be developed for ERP system using decided upon mapping (depends on F1-S3 to start)
          F1-S6 Orchestration flow between the connectors any centralized business logic (depends on F1-S4 and F1-S5 to start)

          The Minimum Marketable Feature set for the end-product requires many such integration flows e.g. above is used in Communications industry wherein you can place orders for a mobile phone; the order is fulfilled by doing availability checks, setting up a billing profile, sending information to inventory and shipping ERP modules to ship the phone; reserve phone numbers, setting up voicemail and calling the billing modules to start billing. Each of those is *at least* one integration flow; and ALL the flows are needed in production – tested together – before this enterprise product is considered production ready. No amount of individual service testing with mock interfaces/stubs (we do all that) replaces final integration testing for mission critical systems in any company. Customers would not accept a phone order that keeps billing them without having a dial tone, just because that service was considered production ready in a sprint but did not work when put together with other flows in production. With evolving standards around technology, cross platform interoperability and cross application semantic mapping issues are just too risky to depend on the output of a single sprint as being production ready.

          Getting back…the above sample feature (Sync Order flow) was considered in Analysis phase when one team started work on Story 1 (mapping-the most critical part) since all other stories depended on it. When mapping is done, the two stories that depend on it can start in the next sprint and we consider that feature to be in Build. When the sprint picks up the last story after the web services and connectors are ready the feature is considered in Integration Test phase. And when multiple such features are done, the last step is the hardening / System Test sprints to ensure production readiness of the product i.e. upon placing an order, your phone is shipped, a number reserved, dial tone enabled and billing started with all discounts applied.

          How does it give business agility? Each integration flow is what is worked on at any given point in time throughout its “tier 2” lifecycle. Any business change could now be addressed in 3-4 weeks, whereas prior, it took approx 4-6 months or more. Projects are not stuck in one phase – at any given point some flows are being mapped, others developed, others tested and many are ready for demo. Each integration flow is delivered and demo’ed with 2 sprints, whereas the earliest it could be seen earlier was 6-9 months. The focus is now on providing business value at the earliest and while a certain number of flows are still essential, they can be prioritized by the business, new flows can be added etc.

          The approach does not fit a waterfall in 2 week (or 3-4 weeks as per the tip) sprints as you suggested; instead it breaks it up but still maintains the overall phases for practical tracking and management purposes, similar in intent to your Tier 2 Kanban. I really liked that concept and will to adapt more to that pattern.

          To me, agile is a tool – it is simply a means to an end, not the end-goal in itself. If this is not agile for very complex enterprise use cases like these, I don’t know what is.


  2. I found that picking a good ALM tool at the start of the Agile rollout helped in a big way. The tool gave consistency, provided process guidance to the teams, and told us how we were doing. We specifically used the Rally tool to great effect, but I suspect other ALM tools would work just as well.

  3. Pingback: Project Management At Work » Blog Archive » Weekly project management news roundup: Tips for adopting Agile; Top 10 issues implementing Agile; Implementing Agile when not everyone is a believer, and other interesting posts

Leave a Reply