Tag Archives: agile

How Agile is your Organization?

Maximum flexibility requires maximum responsibility!

Being Agile as an organization and Agile application delivery has been on the radar of many CIO’s and CTO’s trying to reduce the time to market of systems under their control.  Often I see agility being interpreted by the other C-levels as a methodology for maximum project flexibility. However maximum flexibility requires maximum responsibility to achieve business value and that is not a solely technical issue, on the contrary!

Being effective in Agile delivery requires a lot of maturity in different areas during project delivery. We will be looking at six axes besides the typical technical one:

  1. Technical Environment
  2. Quality Management
  3. User Experience
  4. Team Dynamics
  5. Ownership Management
  6. Project Management
  7. Company’s Eco-System

To generate maximum value, the Agile methodology has guiding principles and these have to be translated in operating procedures. Based on earlier work of M. Balbes, we propose a model to quantify this operational effectiveness by scoring a list of required capabilities according to maturity going from no capabilities to innovating and leading capabilities.

An Excel version to score your organization can be downloaded here:

Before we try to measure something, what are the Agile principles companies should adhere to?

  1. Delivery Value: Focus on continuously delivery value to the customer, key-users …
  2. Embrace Change: Change is good and inevitable. Change avoids waste by adapting before it is too late.
  3. Business + ICT: Avoid Chinese walls between teams. Work closely together every day.
  4. Simplicity: Focusing on what is good enough to avoid gold-plating. Work smarter not harder.
  5. Frequent Delivery: Delivery version frequently to have short feedback cycles.
  6. Self-Organizing Teams: Motivated individuals will be able to identify how to organize the work and what they need.
  7. Communication: Transparent, open and face-to-face communication helps insights and clear understanding.
  8. Self-Emerging: Avoid analysis-paralysis and big design up-front. Design for what is needed now and adapt.
  9. Progress Monitoring: Measure progress as delivered software i.e. potential shippable product increments.
  10. Constant Pace: The team should work according at a pace they can keep up without feeling pressured.
  11. Technical Excellence: Focus on the quality of artefacts and development process.
  12. Continuous Improvement: Be self-reflective and make incremental improvements to the development process.

For the different axes an organization needs to have some capabilities in place and below some examples of these capabilities. The detailed list can be found in the attached Excel model.

Technical Environment capabilities check if the principles of extreme programming are enabled. What is the company’s maturity for following capabilities:

  • Unit testing, test driven development and technical testing approaches
  • Continuous integration methods
  • Pair programming – Spikes experimentation
  • Source control – Branching strategy approaches
  • Release management
  • Coding standards usage
  • Development process – Software Development Life Cycle
  • Shared code ownership
  • Software changeability enablement

Quality Management validates if quality assurance is taken in favor of quality measurement. What is the company’ maturity for following capabilities:

  • Quality management process
  • Code Quality – Internal – External Quality impact analysis
  • Team’s  ownership of quality
  • Defect management
  • User acceptance testing – Exploratory testing

User Experience looks at the application of multi-disciplinary teams since developers are not designers. What is the company’s maturity for following capabilities:

  • Graphical Design – UX selection process
  • Embedded usability testing

Team Dynamics focuses how people collaborate and how self-reflective they are. What is the company’s maturity for following capabilities:

  • Team Structure – Charter agreements
  • Team discussion – Conflict resolution processes
  • Retrospectives – Stand-Ups organizations
  • Information radiators availability
  • Continuous improvements
  • Change acceptance process

Ownership Management goal is to see how well the link between business and IT is managed to enhance a project’s business value. What is the company’ maturity for following capabilities:

  • Identified stakeholders management
  • User stories – Story sizing principles
  • Acceptance criteria – Owner acceptance process
  • Delivering value – User feedback management
  • Prioritization – Backlog – Release Cadence organization
  • Backlog – Change management

Project Management looks for transparency in reporting and collaboration enhancement. What is the company’s maturity for following capabilities:

  • Kaban – Milestones overview
  • Decisions – Meeting minutes creation
  • Staffing alignment

Finally we have the company’s Eco-System or the environment. What is the company’s maturity for following capabilities:

  • Risk Identification – Monitoring – Mitigation
  • Embedded learning culture
  • Change – Champions creation and management
  • Governance – Internal Change – External Change management

An overview presentation can be downloaded here:

Building Evolutionary Architectures

Controlling the Fitness of Your Software Architecture!

In their book “Building Evolutionary Architectures”, N. Ford, R. Parsons and P. Kua introduce a new way to look at software architecture where changes to requirements become part of the business as usual. These concepts were already set in motion by Agile, DevOps and CI/CD but the authors add a refreshing concept to the mix.

How are we going to measure the suitability of our architecture compared to the every changing requirements?

The proposed solution lays in measuring how far or how close the characteristic of the current architecture are from the ideal or expected characteristics. The solution was inspired by statistical models were we want to fit a curve to a set of data points by fitting a function. An expression of the suitability of the curve’s function is called the fitness of such a function.

The same concept can be applied to software architectures. Required architectural characteristics a.k.a. as the technical *-abilities can be measured by fitness functions. When the architecture changes the impact is measured by these fitness functions and as a result the changes become quantifiable and controllable.

An architectural fitness function provides an objective integrity assessment of some architectural characteristic. Combining the outcomes of the collection of fitness functions gives a view on the overall architecture.

Making architecture capable of evolving requires 3 things:

  • An architecture that supports incremental change
  • An architecture that can be measured so the changes can be guided
  • An architecture with the appropriate level of coupling to allow for an optimal change process

More details on the topic can be found in:

Tearing Down the Application Development Fortress

A plea for multi-disciplined development teams

Introduction

Creating applications is a multi-skill effort that comes with a set of challenges. For an average sized application there are 5 skills involved:

  • Graphical design
  • Business analysis
  • Application development
  • Software testing
  • System operations

… not even taken into account other stakeholders like end-users, DBA’s, enterprise architects, security officers, project and program managers, change management, user experience design …

Continue reading

“Lean, Agile Techniques and Team System” Joel Semeniuk

[MS Techdays 2009] Summary “Lean, Agile Techniques and Team System” Joel Semeniuk

Introduction
The probability of success with a team of medium skilled developers working together is greater than the chance of success of a team of excellent developers not working together.

In his presentation, Joel Semeniuk gives us seven myths about software development and some solutions to overcome these. He has taken ideas from other industries amongst others the manufacturing of consumer goods and applied it to software development.

He started off with a quote of Toyoda’s principle from 1927 “If something goes wrong. Stop everything and fix it once forever.”

Myth 1 Early Specs Reduce Waste
Tell me everything you need into the finest detail and we will not make errors creating it.

The principle is to avoid waste. Waste is everything that is not adding value or preventing value to be created. What is value and what waste remains subjective!

Waste consists of:

  • Partially done work: avoid inventory of work to be done, one flow: develop – test – document
  • Extra features: not asked means no added value
  • Relearning: pass on learned lessons
  • Handoffs: handoffs are evil because you?l lose the problem context, use face to face communication and not only documents to pass information
  • Task switching: try to work as long as possible on the same task, it takes humans about 15 minutes to get from one task to another [Book Peopleware: Productive Projects and Teams by Tom DeMarco and Timothy Lister]. Set aside time for triage work.
  • Delays:  what to do when information is unavailable? Stop, switch task or guess? Collocated teams of users, developers, testers Šwork the best.
  • Defects: try avoiding mistakes but try to find mistakes as soon as possible or even better try to avoid making them. Inspect to prevent defects!

Myth 2 The Job of Testing is to Find Defects!
Build quality in from the start and avoid creating defects in the first place. Inspect often to find defects if you can’t prevent them. Once you have found a defect fix it so it never occurs again.

Example: Visual Studio check-in policies enforces best practices of quality gates.

Myth 3 Predictions Create Predictability!
We don’t plan to accurately predict the future!

Predications will be wrong if they

  • are complex,
  • must be detailed,
  • are about the future and
  • are dealing with uncertain environments.

The problem is that predictions are considered commitments (see myth 4).

We can deal with this uncertainty by:

  • Short feedback cycles
  • Detailing along the way
  • Releasing quickly with few but completed features
  • Having an experience team leader

Example: Team System support progress tracking of work items.

Myth 4 Planning is Commitment!
Eisenhower said in preparing for battle I have always found that plans are useless, but planning is indispensable!

Get in the process of frequent re-planning:

  • Wait until the last moment, you will have more information!
  • Make decision that reversible but avoid full flexibility.
  • Plan thoughtfully but commit sparingly

Myth 5 Paste Makes Waste!
Detailed planning ensuring we do it right the first time, mostly results in endless planning without ever starting the project. Companies that compete on time have considerable cost advantages over competitors.

Focus must be on:

  • Short feed-back loops
  • Repeatable reliable speed

Example: coding conventions and code analysis enforce automated quality control.

Myth 6 There is One Best Way!
Continuous improvement showed that there is no such a thing as the best way. A process can always get better and people are the cornerstones of the improvements. So you should embrace the people. Software development is a people process!

Myth 7 Optimize by Decomposition!
Optimizing of all the individual parts only leads to a sub-optimal result for the whole. Optimize the Whole!

Value based process improvements are the driving power for this. This means metrics or measurable results.

Examples: use a white board in the team to visualize performance and to gather lessons learned. Team System supports the gathering of performance metrics and putting these in SQL Analyst Cubes for reporting and analysis.

Conclusion
During the last decade some of the best practices and frameworks come closer together to support a more mature approach to software development. We see following approaches mutually enforcing themselves:

  • Test driven development
  • Feature driven development
  • Scrum
  • Prince 2
  • Lean

Distributed Teams and Agile Development

On a project I’m experiencing how difficult it is to work with a geographical distributed team. We rely on web-conferencing and just finding a free meeting room at any time, with a projector, to discuss open issues is not easy.

On the one hand bringing people together in one pace is costly because of travel expenses. On the other hand there is nothing like face-to-face communication that is hard to mimic even with the latest communication technology. It is not easy to find the correct balance between travel expenses and communication efficiency.

I was just wondering what agile development has to say about geographical distributed teams, when I ran into a Pattern & Practices document of Microsoft:
Distributed Agile Development at Microsoft patterns & practices. There are no chocking new things in the document but I give you some personal highlights in the case you?l don’t have the time to go through the whole document.

Collocated vs. Distributed teams
One of the best practices of Scrums says your team should have high-bandwidth communication. This is one of the forces to collocate them in one “team-room”.

The force that distributes teams geographical is globalization. Global markets mean that your workforce has become distributes over the world during mergers and acquisitions. Talent has become global as well. You might need the input in your project of one expert located in the other end of the world. Like I said above, you?l want to reduce the costs of bringing the team together.

Challenges

  • How to achieve optimal communication?
  • What to do with teams in different time zones?
  • How to avoid artifacts are affected?

    Conway’s Law says the artifacts will reflect the organizational structure that produced it.

Optimal Communication
Minimize the overhead of setting up meetings across locations. This means that your teams should, very early in the project, get used to the conference technologies to avoid any hesitation in using them. Getting the team in the habit of using the technology and making communication one of their duties is key.

Different communication technologies are available but shouldn’t be that high-tech. A phone with a headset might do! Other options are electronic sharing of documents in web conferences (MS SharedView), video or phone conferences. Instant messaging or webcams might suffice as well.

Get your team acquainted to avoid us’s vs. them’s discussions. You should bring your team together once and while to build a social fabric. Avoid the team members to change too often. Every release at least half of the team members in one location shouldstay the same!

Optimal communication is supported by the right tools. For example Teams System supports electronic scrum boards to be shared by the whole team. Good tools should adhere the natural flow of work.

Different time zones
In the case you?l have teams working in non-overlapping timezone’s, there will be communication black-outs. The strategy is to have team members working late or start early to create at least one common moment that someone in both sides is available.

Give those persons a store-and-forward role in the communication: gather information from the other site forward it to the team-members at his site and forward the information from the team-members of his site to the other site.

Some pitfalls:

  • Functionally focused distribution: testers in site A and developer at site B can result in knowledge silos.
  • Asymmetric distribution: 1 person in site A and n persons in site B can result in losing the ability of keeping the one person up-to-speed with information.

Distribution of work
Force the teams to think in the context of the results meaning in use cases or stories. Avoid that work is functionally distributed over sites. For example one site implementing only the data access related component and another site doing the user interface controls. This can be done by appointing stories to a site and not individual tasks from the stories.

Do and don’ts

  • Do: provide technology for high bandwidth communication
  • Don’t: change the team too often
  • Do: bring the team together
  • Dont: functionally distribute the work
  • Do: provide tools that can make the team work together as they would do if located in one room
  • Don’t: forget remote members
  • Do: improve the team practices to encompass the geographic distribution by gather possible improvements from retrospectives and coaching the agile practices