The Maturity Model

The Maturity Model

This is ThoughtWorks Maturity Model for the software development and can be easily translated to the agile environment.


Practice Build management and continuous integration Environments and deployment Release management and compliance Testing Data management
Level 3 – Optimizing:
Focus on process improvement
Teams regularly meet to discuss integration problems and resolve them with automation, faster feedback and better visibility. All environments managed effectively. Provisioning fully automated. Virtualization used if applicable. Operations and delivery teams regularly collaborate to manage risks and reduce cycle time. Production rollbacks rare. Defects found and fixed immediately. Release to release feedback loop of database performance and deployment process.
Level 2 – Quantitatively managed:
Process measured and controlled
Build metrics gathered, made visible, and acted on. Builds are not left broken. Orchestrated deployments managed. Release and rollback processes tested. Environment and application health monitored and proactively managed. Cycle time monitored. Quality metrics and trends tracked. Non functional requirements defined and measured. Database upgrades and rollbacks tested with every deployment. Database performance monitored and optimized.
Level 1 – Consistent:
Automated processes applied across whole application lifecycle
Automated build and test cycle every time a change is commited. Dependencies managed. Re-use of scripts and tools. Fully automated self-service push-button process for deploying software. Same process to deploy to every environment. Change management and approvals processes defined and enforced. Regulatory and compliance conditions met. Automated unit and acceptance tests, the latter written with testers. Testing part of development process. Database changes performed automatically as part of deployment process.
Level 0 – Repeatable:
Process documented and partly autoamted
Regular automated build and testing. Any build can be re-created from source control using automated process. Automated deployment to some environments. Creation of new environments is cheap. All configuration externalized/versioned Painful and infrequent, but reliable releases. Limited traceability from requirements to release. Automated tests written as part of story development. Changes to databases done with automated scripts versioned with application.
Level -1 – Regressive:
processes unrepeatable, poorly controlled and reactive
Manual processes for building software. No management of artifacts and reports. Manual process for deploying software. Environment-specific binaries. Environments provisioned manually. Infrequent and unreliable releases. Manual testing after development. Data migrations unversioned and performed manually.
Sprint 0 tasks

Sprint 0 tasks


• Defining Scrum Team. 

• The Product’s pre sales estimation is already handy. 

• The stake holders are aware of Agile and Scrum. 

• Delivery In charge / Client Servicing if required is in place and understands the product. 

• Metrics to monitor the product progress in terms of monthly reporting is being decided depending on the Fix Cost – Fix Scope or Managed Team model. 

• DevOps or Architecture team is available when required, such teams would be available in initial Architecture / Environment finalization. 

StakeHolder’s Vision Call 

• A direct call with the Stakeholders, so that everyone on board should be introduced to the Stakeholders. 

• Profile if required should be shared with the Stakeholders. 

Infrastructure preparedness 

Depending on the requirement of the product environments & tools need to be setup. 

• A Typical Environment Structure would be. 1 DEV + 1 STAGING / DEMO + 1 Production 

• Tools like JIRA / Confluence / Stash needs to be setup depending on the scale of the product. 

• Communication Tools like Dropbox / G Drive + Slack needs to be setup as well for swifter and Faster Communication 

• If client needs to monitor Epic level progress on some other tool then Asana / Trello can be used. 

• Calendar Invites via Google / Outlook is a must. 

Architecture and other tasks: – 

• Application architecture should be in place. 

• Server architecture should be in place. 

• Database architecture should be defined. 

• Database recovery and daily back up plan should be in place. 

• If cronjob’s are to be used then their architecture should be defined. 

• Disaster recovery should be in place. 

Scrum Preparedness 

• It is assumed that the selected team is already aware of Scrum and Agile and shall easily follow the processes required. 

• If they are not then they shall be trained by the scrum master. 

• A Proper Sprint Calendar is prepared in which the following is finalized 

• Sprint Length 

• Timing of different meetings (Sprint Planning & Sprint Review) along with the Stake holder is finalized so that there is no to and fro for the meetings. 

• Team finalizes the Days for Sprint Start and Sprint End. 

Definition Preparedness 

In order to avoid misunderstanding and discontented clients it is important to finalize certain 

definitions well in advance 

• Definition of done 

• Definition of Ready 

• Coding Standards 

• Initial Architecture / Server Configurations / Application or Frameworks 

• Test Strategy (Manual / Automation) 

RoadMap Clarity 

It is important to have a discussion on roadmap along with the team to give the team a bigger picture which shall keep the team motivated and excited about the product. This needs to be done by the Stake holders along with the Product Owner 

Release Plan Discussion 

• Based on the initial scope a high level Epics needs to be planned and entered in the JIRA for further discussion 

• These Epics needs to be Estimated at the epic level to know what is the estimated size of the first release 

• Depending on the team strength and their velocity an approximate Release date needs to be finalized and it should be communicated to the team. 

Product Backlog Creation 

• The High level Epics needs to be prioritized whether they are technical (framework installation or DB design) or business epics or features 

• Epics for the first and the second sprint needs to be groomed into multiple stories so that they can be estimated at the story level as well. 

• These stories also need to be prioritized depending on the dependency as well as business value. 

• The Grooming of these stories are important to start the Sprint 1.

*This list was taken from the internet – I believe some LinkedIn post and will be altered

May The Force Be With You

May The Force Be With You

Scrum and agile practices are important. They are good for establishing healthy habbits and discipline needed for project success. On the other hand I’ve seen many teams, putting Scrum practices into work, but still failing. I was thinking about this, talking to people about what they think and feel, gathering all these information to very useful experience, I want to share with you. There can be a lot of reasons why guys with good Scrum practices fail. I will not talk about surface reasons, but instead, I would like to take you to a deep dive path. When talking about how deep something is, I will use Neuro-Logical Levels from Robert Dilts. I won’t get deep into this matter, since it would take too much space and time and I might use it for another article, but I want to explain shortly what it is about.


Seeing this picture we might easily conclude that higher the level of comprehension is, the deeper impact it make. So, when talking about values and beliefs, we are coming to some deep and intimate impact they have in our life, private and business as well. In many articles, impact of company culture and values to individual is described and I want to talk about values impact to software development process and Scrum values impact to Agile/Scrum transition success degree.

As you probably already know, Agile Manifesto defined what we, in Agile world, value and what principles we respect and keep up to. This traced a path to many concrete agile practices, which, further on, brought improvements to many software teams. That’s why Agile Manifesto impacted the software world so hard in extremely positive way. From these values came concrete competences, behaviours and environments which supported and were greatly aligned with these values. Look for a moment at NLN pyramid and you will see that competences, behaviours and environments are manifestations of the implemented values.

With Scrum, more values, which are mirroring Agile values and are fully compatible with them, are introduced. If you can align yourself and your team with these values and all of you truly believe in them, I’m sure that putting Scrum in practice will be much easier for you and for your team.

Acronyms are easier to remember. Besides that I’m great Star Wars fan and I always liked, since my early childhood, Jedi knight greeting each other with “May the Force be with you.” It seemed so noble and positive.

– Developers are focused on development (technical stuff).
– More developers working together on the same tasks – focus is on getting things done, not on personal agendas.
– Daily Scrums are bringing work and details to the focus.
– Sprint backlog -> we’re focusing on iterative/incremental chunk of product fully developed and deployable.
– PBL refinement -> bringing “closer” user stories to team’s focus
– Sprint planning -> deep focus on detailed technical implementation and even more, splitting to tasks focus even more.
– Sprint retrospective is focusing the team on concrete actions needed to improve.
– Demo – focusing on work delivered and really working features -> valuable feedback from stakeholders
– PO focused on PBL, and bringing valuable user stories to really working state

– Daily Scrum is open, frenkly sharing of work done and issues met on this path.
– Retrospective – we openly speak about dysfunctions, issues etc.
– PBL and SBL are open to all (permitted) and are subject of change.
– We’re open to all changes, and we openly give arguments pro and cons, openly discussing and accepting neccessary changes.
– Our work is transparent towards our stakeholders and we share what we do on the demos. Also we are accepting all suggestions and ideas, which PO will filter to final user stories.
– PO accepts and discuss ideas about product with the team
– We are reviewing each others code and are accepting suggestions

– We respect each other in the team. We trust in other team members’ work, we share the code and we’re open to code changes from the others.
– We respect our PO, fully trusting that she made right decision for the product
– PO respects the team and trusts the estimations and the feedback regarding product
– Stakeholders respect the team and the process and not interfering in the development process and leaving the team to develop in peace

– We have no fear of conflict – we are straight, but stil polite (respect) towards our team members and stakeholders
– We are allowed and encouraged by each other to try the new ideas and there is no fear of fail. The sooner we fail the better for the product.
– We bravely tell if something is wrong with the process, the team, the product or ourselves.
– We have courage to ask for help if needed, since this is better for the product and the team. Getting neccessary help, we learn. Also, we learn helping others.

Engagement (instead of Commitment)
– We do believe in what we do. We believe that we are creating the product of the great importance and which will impact people. We are really engaged in creating and improving great product.
– We are striving towards technical exellence and agile practices are helping us on this path. We are engaged in constant improvement – in technical area as well as in process
– On all our ceremonies, we are engaged and we contribute
– We don’t need commitment and promises. We are honest and we are sincerely engaged. Every day, we are starting our work  with excitement and happiness going through challenges helping each other. We are getting things done, which raises level of engagement for a new work to be done.

List of Agile Practices

List of Agile Practices

  • Short iterations
  • Prioritized backlogs
  • Backlog grooming
  • Release planning
  • Iteration planning
  • Iteration reviews
  • Test-driven development
  • Refactoring
  • Continuous integration
  • Automated acceptance testing
  • Unit testing
  • Retrospectives
  • Collective code ownership
  • Single team (integrated dev & test)
  • Dedicated product owner
  • Pair programming
  • Open work area
  • Taskboard
  • Daily standup
  • Coding standards
  • Kanban
  • Behavior-driven development (BDD)
  • Continuous deployment
  • Agile games
  • Story mapping
  • Team-based estimation


  • …and growing