With skeptical doubts in software delivery and support services, mid-size companies often introduce agile to test waters and get excited with benefits of quick value delivery. Application Features which took 8-10 months in “waterfallish” delivery model are now developed (not delivered – just previewed) in 4-6 weeks “agilish” way!!!!
You see – we are agile, we always talk about minimum viable product development and will show application GUI on tester’s screen. Software release and delivery will be done “later”. (read: its not my/our problem!!!!)
Suddenly everybody goes gung-ho about agile as the next best thing happening in our company and executives push for expanding agile in all projects and in every business area as they are seeing application GUI every couple of weeks.
Talk to new highly re-charged hyper Adrenalin filled agile guys about software development life cycle (SDLC) best practices, delivery and automation and often you hear some of the common interesting defences:
- We have just started on our agile journey. Design and development will use agile. Release and delivery will be done by vendors in waterfall way. They are still traditional – we are agile.
- Agile should show some output and outcome first before we invest into it further.
- Focus on solution development, don’t want overhead of documentation, practices, procedure, planning and automation. We want “light weight” agile. Devops in not agile.
In summary often mid-size companies are pushing for scaling agile in projects development and skipping agile in basic SDLC practices including automation, change management, release, etc.
I often see following scenarios where agile cowboy approaches supersede disciplined agile.
Scenarios 1: Agile teams complained regularly about business guys are unpredictable. They are not sure what they want resulting in our iteration planning meeting dragging for first 2 days in 2 weeks iteration.
Scenario 2: We cut corners on testing as 2 weeks iteration is too short to complete iteration backlog and test automation platform setup is company responsibility not our agile project responsibility.
Scenario 3: We are agile teams, user story drafting is the only documentation we follow. Release planning checklists, vendor SLA’s and test strategy are old waterfallish approach. Nah we don’t do it.
Scenario 4: we are not responsible to contact vendors, infrastructure support, change management team, security team and performance testing experts as it’s not our responsibility.
Symptoms sounds familiar in your company too… !!!
Now the question is, what should you do when you realize this full-on?
1) To start with
- Introduce mandatory training for entire SDLC teams, managers and executives in mindset of “being agile” + “doing agile”.
Secondly: Set your house right
- Possibly setup your cloud platform for SDLC including release and deployment depending on your technology and business complexity needs.
- Define and develop your DevOps practices including automation to support agile SDLC.
Finally: Build value culture
- Don’t isolate traditional project teams from agile teams (in-house, vendors, partners & offshore). Build living and learning SDLC culture with Cross team collaboration, ideas and domain knowledge sharing, learning from practices and experiences of team members.
- Push for openness, collaboration, transparency and experimentation culture of fail fast, fail cheap and learn.
2) Light-weight agile
- Often mid-size companies don’t need heavy-weight and highly scalable agile models to scale agile across organization. Light-weight approaches such as Nexus framework, Fast-Agile, ScALeD Agile Lean Development, Large Scale Scrum, Spotify can help solve your enterprise agile scaling.
3) Continuous Value Delivery
- Don’t start multiple agile projects with dedicated Product Owner – Scrum Master – Delivery Team model. Instead go for common backlog for strategic business initiative and break it down into tactical business value solution and form agile release teams to deliver tactical solution rather than dedicate agile projects.
Example: Digital channel as strategic business initiative with common backlog for multiple agile release teams for online features, mobile features, web optimization, etc.
- Include new features, features enhancement, features modification and defects fixing in your strategic backlog and run your tactical release team in Kanban or agile for business as usual (BAU) model instead of time-boxed agile sprints.
- For DevOps, Start with best practices implementation, SDLC test automation, continuous build, continuous integration and finally with continuous deployment. Experiment with open source tools (some are here, here & here). Suggestive recommendation list can be found at Forrester.
- Agile @ operations level demands better discipline. Define clear Definition-of-Done for business value hierarchy starting from Feature à Epic à Story for better traceability and for speed to value.
- Include security, architecture, support services, change management and other units in strategic planning and use their experience in tactical solution definition. Remember we are all together in value delivery.
Don’t be fooled by taking prescriptive “blueprint” down off the shelf (from either a vendor or “standards” body or certified agilist). Experiment under the guidance of experienced coach with working methods, tools, team structure, etc.
We all need guidance and help to scale and expand agile culture. Vendors sharing other companies case studies that explain “we’re expert in this trade and we did these things to scale agile and we had always these positive outcomes might not help you as your culture, competencies and business demands may not be same. Your speed and mileage of scaling agile may vary. Please don’t get fooled by “Make your enterprise agile in guaranteed 100 days” programs as Rome was not built in a day my friend!!!!
Your thoughts: How you scaled agile culture — and what you did?