Much of the objection to SAFe comes from its seemingly Top Down paradigm. Many agile voices object that this approach is not agile, in the way they define agile - individual teams making their own decisions about what to do with their customer.
The domain of this bottom up approach is usually not well defined, other than the classic eXtreme Programming or the Agile Spectrum of Guy Strelitz where Co-Hacking is on the left, where the developers live by the pure agile manifesto.
But what happens when agile is applied to an enterprise development effort. One where the business needs define the capabilities that are not emergent, but rather they are needed to fulfill the business strategy or the mission of the organization. Then another paradigm emerges. One where higher order questions, frameworks, framing assumptions, governance, and other externalities trump the needs of the individual team.
Here's one approach that has served us well over time.
- The structure and teaching of SAFe is relentlessly top down. All the important stuff is figured out up in Portfolio. All the features are figured out up in Program. Now you guys Build and Test that.
The statement is a bit off, since it's the Capabilities that are defined by the business. These capabilities are then turned into requirements, which may in fact emerge, which themselves are turned into working software. Starting with the capabilities, an enterprise software development effort means re-looking at the agile manifesto statements.
-
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- It certaintly is the highest priority to satisfy the customer with valuable software.
- The delivery in the enterprise needed to be planned at the absorption rate and business rhythm.
- The units of measure of value need to be connected to the business strategy. This is usually to role of Balanced Scorecard, which defines the value in the 4 perspectives of the business.
- Financial
- Customer
- Internal business processes
- Learning and Growth
- Here's how to develop your BSC for enterprise software development.
- Releasing software in the enterprise means integrating with the business processes, customer processes, product release process - all defined by the rhythm of how the business works
- Imagine updating the point of sale terminals across 10,000 users on a daily basis, adding new features, changing possibly for the better how they work.
- The training, Tier 1 support, transaction formatting, and other enterprise actiities woudl alos have to change.
-
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
- This is one of those untested statements.
- Imagine changing how ICD-10 claims are processed late in the development cycle.
- Other enterprise systems are based on ICD-10 formats, now they're changing as we approach "go live."
- We need look no further than the ACA roll out to see how nonsensical this is.
-
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
- For the enterprise, the business rhythm defines the frequency of software release.
- For example, the flight navigation systems for an aircraft have many other processes beyond just writing code.
- Full Information Assurance, DO-178 validation, Digital Flight Bag integration, PCI
- For health care SP-600 for HIPPA verification and validation.
- Or for the IT Enterprise ISACA.
- Externalities drive business rhythm. Having the developers decide this rhythm ignores these externalities. If there are no externalities, then the project is likely perfect for the agile manifesto.
-
Business people and developers must work together daily throughout the project.
- This works when the business people don't have day jobs.
- If they have day jobs, some proxy of the needed capabilities, and requirements is needed.
- This is the role of documentation and models. Both developed concurrently with developers and business people.
-
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
- Can't go wrong here.
- Remember thought, trust but verify.
- The value at risk needs to be considered. What happens if what the developers say turns out not to be the case. How much are you willing to risk that the trust was misplaced?
-
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
- Back to the availability issue.
- Geography is another issue. Many teams are distributed.
- Face to Face needs a proxy.
-
Working software is the primary measure of progress.
- Correct, this is basis of Earned Value Management's Physical Percent Complete.
- Working needs a definition. Measures of Effectiveness, Measures of Performance, Key Performance Parameters, Technical Performance Measures are all mechanisms to assess the workingness of the software in the enterprise domain.
-
Agile processes promote sustainable development.
- All work processes should be sustainable, nit just agile.
- Knowing the capacity for work is the starting point.
- This means not only knowing the capacity, but planning the work around this capacity with the needed margin to provide for sustainability.
-
The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
- Yes, good business and engineering practice.
- Requires capacity planning
- Cost, Schedule, and Technical margin.
- Measures of performance to make steering adjustment and needs a control system to connect the dots between the desired outcome, and actual performance, and the corrective actions needed to sustain this needed performance.
-
Continuous attention to technical excellence and good design enhances agility.
- This is a platitude that is used in all engineering domains.
- rarely if ever are product build with low technical excellence and good design practices.
- Exactly how this enhances agility is untested outside of anecdotes.
- But certainly changeability in response to external factors is measurable as robustness of the design.
-
Simplicity - the art of maximizing the amount of work not done - is essential.
- Another platitude, without any actionable suggestions.
- But what are the units of measure of simplicity.
- Everyone should read Synthesis of Form, Christopher Alexander.
- Then the practice for enterprise projects, The Art of Systems Architecting, 2nd Edition, Mark W. Maier and Eberhardt Rechtin.
- And followed by Systems Engineering: Coping with Complexity, Richard Stevens, et al.
- These three books address the platitude and replace it with actionable steps to maximize value produced with minimal work.
-
The best architectures, requirements, and designs emerge from self-organizing teams.
- In the enterprise domain this is a non-starter.
- Architecture is the glue to holds the systems integration together.
- Emerging architectures means, all the other systems in the enterprise will be constantly changing as the architecture of the system under development changes.
- Those self-organizing teams may or may not have the skills, experience, and even ability to be systems architects.
- Read the systems engineering books above. Join www.incose.org to learn how complex enterprise systems are defined, developed, deployed, and maintained.
-
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
- This is standard good engineering practice, not unique to agile.
So What Does All This Mean?
Without a domain, hard to assess the applicability and appropriateness of much of anything.
What this really means of Scaled Agile Framework is the place to start for the enterprise.
