Online presence of Craig Smith — Agile Coach & IT Professional in Australia

Archive for the ‘Book Summary’ Category

Enterprise Software Delivery (Book Review & Summary)

Enterprise Software DeliveryI recently completed reading Enterprise Software Delivery by Alan W. Brown. I read and reviewed the book for InfoQ and the following is my brief review and key notes from the book.

Review

This is a book that sums up any large organisation with a software delivery function. It certainly matches the experiences in my last company but also matches the many case studies I have heard from my colleagues over the years.

It starts by defining enterprise software delivery, noting it uses the word delivery and not development. This is on purpose as software development is only useful when in the hands of the end-user.

The key focus areas are:

  • software supply chain and factories – a large portion of the book points to understanding the entire delivery process and understanding how to deal with distributed teams (whether they be within the organisation or partnered or near or offshore)
  • collaboration – the importance of collaboration and the use of collaborative delivery environments (CDE) and collaborative application lifecycle management (CALM)
  • agile – the importance of agile and approaches to rolling out and scaling in the enterprise
  • quality – the importance of building quality in as well as quality of the team and its relationships
  • governance – measuring your delivery and managing your team and partnerships effectively
  • future – trends that are starting to effect enterprise software delivery including cloud, multisourcing, crowdsourcing and mobile

The Agile portion of the book had me either in agreement or in a couple of cases opposition. I could understand the viewpoint of the author — for example the use of software testing factories which I think removes a lot of the collaboration that is possible with Agile testing techniques and tooling. The author is the CTO for IBM Rational in Europe and as a result a lot of IBM thinking comes through in the ideas. Whilst this is not a bad thing, it is useful to remember that the IBM approach is not the only approach.

The book has lots of case study material (mostly revolving around the financial industry and Danske Bank as well as IBM itself). There are a number of figures and illustrations throughout that demonstrate the points that the author is trying to make (like examples of metrics, processes and plans) and and these alone make the book a valuable asset for those times when you are looking for an example to get started.

This is a book that all technical leaders (including developers, architects and CIOs) should read if they are involved in software delivery in a large organisation. This was a book that I admit I struggled with a little as I read it, which I think was because I had spent so much time in a large organisation that had a continuous focus on governance, sourcing and agile. But on reflection, there were lots of ideas and trigger points throughout the book that are calls to action. Of course, for those just venturing into this domain, it is a recommended read.

Overall, this was a worthwhile read and a book that I would summarise as being very good for lots of ideas rather than a playbook that you follow from beginning to end.

Summary

Here are my key notes from the book:

  • agile “steering” leadership style - frequent course corrections based on testing, measurement, and trends in defects and cost-of-change
  • economic pressures have focused attention in enterprise software delivery organisations on cost-cutting activities, severely stretching existing delivery practices
  • CRASH Report - examined 288 deployed enterprise applications from 75 organizations (with more than 108 million lines of code) and found structural errors that on average would require an investment of more than $1 million per application to fix
  • must learn how to balance the relationship between necessary investments in enterprise software delivery and the business value these investments bring to the organisation
  • inefficiencies and misunderstandings are a major source of errors, frustration, and waste. Clear approaches to communication and coordination greatly improve the team’s performance
  • early and continuous attention to quality is essential
  • adoption of an industrialised approach places the focus on cost efficiency, reuse, and standardisation in enterprise software delivery
  • best-in-class product and services companies are those that have built a strong competency in enterprise software delivery—approaching this as a core business process. Their attention is placed on enabling innovation, lowering costs, and managing change
  • Application assembly optimization (AAO) – consist of centres of competency, technology assembly centres, collaboration and measurements and lean processes – uses work packets to deliver work (self-contained unit of work, the receiver designs, plans, and executes the work requested and measured in real-time)
  • software testing factories - particularly effective in organisations that are more complex, with numerous departments, vendors, and locations - cost-efficient and effective testing on-demand, standardised business-driven test processes, centralises test equipment, common approach to metrics and measures, centralisation of test service requests
  • important insights for an industrialised view of enterprise software delivery – new ideas needed around monitoring progress and managing status, focus measurement on broader SLA’s across vendors, transparency across the chain is critical,  choose different partners for specialist tasks and to reduce risk and increase flexibility and competition
  • an extreme version of multisourcing is the use of crowd sourcing for component delivery
  • collaboration is king – trends –  globalisation, outsourcing, faster time to market, agile, end user demands
  • organisational arrangements for collaboration – internal partnerships (many companies operate software development as a separate legal entity), supplier partnerships (strategic alignment between both parties), outsourced partnerships (formal SLA between parties)
  • global approach – reduce labour costs, skills in short demand, gain access to emerging markets
  • points of friction – “energy is lost in their execution which could otherwise be directed to more creative activities that contribute directly to the completion of the project’s mission”
  • time starvation – “typically never enough time to complete everything on an individual’s to-do list”
  • collaborative application life-cycle management (CALM) focuses on the synchronization of the entire team and the hand offs that occur across domains
  • balance delivery capabilities – time to market, productivity, process maturity and quality
  • the approach to agility – “an iterative and incremental approach performed in a highly collaborative and self-organizing manner with just the right amount of ceremony to frequently produce high quality software”
  • investment should be placed in techniques that support and encourage software to evolve - critical phase comes after first release
  • evolutionary view  - distinction between these two activities is blurred to the point that development and maintenance are just two aspects of the same need to create and deliver the system
  • agility possible when: high-bandwidth communication and coordination, decisions based on real-time information, continuous measurement and transparency into individual, team, and project progress
  • impacts on the scaling of agile – geographical distribution, compliance requirements, technical complexity, team size, enterprise discipline, organisation distribution, organisational complexity, domain complexity
  • “My experience with several large enterprise software delivery organizations suggests that agile approaches can be successful in almost every kind of development team and in almost all organizations”
  • Agile observations: 1) roles most challenged by agile approaches are Executive Managers, Product Managers, and Project Managers; 2) plan at multiple levels and adopt a “measure and steer” approach; 3) don’t use agile methods for everything, match to optimize success; 4) adapt and harden the agile process as the project gets closer to delivery
  • National Institute of Standards and Technology (NIST) – 80% of development costs are spent on identifying and correcting defects
  • almost two thirds of errors are a result of requirements and design problems, misunderstandings, and omissions, while more than 80% of error discovery occurs in acceptance testing or once the software is placed into production
  • improving quality – automating repetitive tasks, discovering more defects earlier in the life cycle, closer alignment between roles, lowering risk
  • “the quality of the enterprise software is a direct reflection of the organization’s activities, practices, skills, and morale”
  • “the evolution of the role of the software testing factory is toward a utility view of testing as a service that can be readily acquired on a pay-per-usage model or a results-based scheme” – performance and load testing, security testing, compliance testing
  • important aspects of governance – establishing chains of responsibility, authority, and communication and establishing measurement, policies, standards, and control mechanisms to enable people to carry out their roles and responsibilities
  • challenge lies in knowing which metrics are more meaningful in a specific context and how to use those metrics to change the way an organization performs it tasks – one cannot control what one cannot measure
  • a well-chosen set of metrics clarifies the goals of the organization
  • measure what you can, what you value, what drives behaviour and what optimises results
  • decisions that may be considered optimal in one area of the business (e.g., software testing) may introduce challenges in other areas (e.g., deployment management).
  • Walker Royce - analogy between enterprise software delivery and movie making - early stages of the process involve significant “scrap and rework” as part of the creative process and later in the process there must be a great deal of focus on reducing rework to eliminate inefficiencies
  • Royce’s ten management principles for agile software delivery
  • through-life capability management (TLCM) – evolutionary acquisition – each increment provides useful and supportable operational capabilities that can be developed, produced, deployed, and sustained. Major enhancements and preplanned product improvements are managed as separate increments.
  • supply chain operations reference model (SCOR) - ensure that the supply chain is operating as efficiently as possible and generating the highest level of customer satisfaction at the lowest cost
  • lean is a philosophy that seeks to eliminate waste in all aspects of a company’s production activities: human relations, vendor relations, technology, and the management of materials and inventory
  • Bell’s Law – a new platform emerges about every ten years to offer improved functionality in new areas, accompanied by lower prices for existing capabilities compared to those of the incumbent platform
  • cloud-based services are usually viewed as operational expenses because they are “leased” for the time they are needed - the switch from capital to operational expense can be very attractive from an accounting perspective
  • “you ship your organization”—the way you organize individuals and teams will undoubtedly have significant impact on the structure and effectiveness of the system delivered

Category:

Book Summary

Specification By Example (Book Review & Summary)

I was lucky enough to be a reviewer on Specification By Example by Gojko Adzic, and the final version was recently released to print by Manning. And I was stoked to see not only my name in the acknowledgements, but that my quote made it to the cover of the book. The following is my brief review and notes from the book.

Review

“I love this book. This is testing done right.” That is my quote on the back cover of the book, and I meant every word of it. Having been a quality advocate in the agile space for a few years now, this is the first book I have read in a long time which had me nodding my head all of the way through, as it resonated with my ideas on how development teams need to reconsider specifications and testing.

The book starts out by summarising why specification by example is so important and outlines some key patterns for success and then, through examples throughout the book, steps through the patterns pointing out the warning signs along the way. The key steps are to ensure the culture is fit, then approach specification in a collaborative manner, use examples and automate and finally evolving a living document / specification.

I really appreciated the fact that the examples were not just the run of the mill greenfield Java web applications that are used in most books. There is a good sampling of different organisations, most of which are using this technique on existing legacy applications on a variety of different platforms. The book is an easy read for the entire team, which means it can (and should) be required reading for the developer, tester, analyst and project manager. I have encouraged many of my teams to take a look at the book, and a couple of my colleagues have indicated this book helped convince and reinforce why this approach is so valuable.

My only concern when reviewing was the fact that the title of this book may not standout to testers and developers (not perhaps as much as Acceptance Test Driven Development or ATDD might). Currently the community has a number of similar approaches with similar names, although I must acknowledge that the specification by example tag has grown on me over the last few months.

The book does not expend much effort talking about tools in this space, by design, I think this fact makes the book more readable and accessible to a wider audience, but that said it suggests to me that there is still a gap for a good text that matches specification by example to particular tools like Concordion, Fitnesse and the like.

Overall, this book is a definite must read for any teams (particularly agile teams) who are trying to balance or find a decent approach to specifications and testing. It is a good balance of patterns and real case studies on how testing and specifications should be approached in an agile world. It would make my list of Top 5 must read testing books and Top 10 must read agile books. And now I know what the proper name is for the cats eyes that are embedded in the freeway!

Finally, I had some other suggestions for summaries for the book that did not make it to cover, but they are just as relevant of my feelings about the book:

  • “One of the best Agile related books I have ever read. Buy it, read it, recommend it to your colleagues.”
  • “This book sums up the right way to attack requirements and testing while delivering to your customer. A must read for all agile teams.”
  • “I loved this book. I could not stop raving about it to my colleagues. It’s testing done right”

Summary

Here are my key notes from the book:

  • a people problem, not a technical one
  • building the product right and building the right product are two very different things, we need both to be successful
  • living documents – fundamental – a source of information about system functionality that is as reliable as the programming language code but much easier to access and understand
  • allows easier management of product backlogs
  • proceed with specifications only when the team is ready to start implementing an item eg. at the start of an iteration
  • derive scope from goals – business communicate the intent and team suggest a solution
  • verbose descriptions over-constrain the system – how something should be done rather than just what is to be done
  • traditional validation – we risk introducing problems if things get lost in translation between the business specification and technical automation
  • an automated specification with examples, still in a human readable form and easily accessible to all team members, becomes an executable specification
  • tests are specifications, specifications are tests
  • consider living documentation as a separate product with different customers and stakeholders
  • may find that Specification By Example means that UAT is no longer needed
  • changing the process – push Specification By Example as part of a culture change, focus on improving quality, start with functional test automation, introduce a new tool, use TDD as a stepping stone
  • changing the culture – avoid agile terminology, management support, Specification By Example a better way to do UAT, don’t make automation the end goal, don’t focus on a tool, leave one person behind to migrate legacy scripts (batman), track who is/isn’t running automated tests, hire someone who has done it before, bring in a consultant, introduce training
  • dealing with signoff and tracebility – keep specifications in a version control system, get signoff of living documentation, get signoff on scope not specifications, get signoff on slimmed down use cases, introduce use case realisations
  • warning signs – watch out for tests that change frequently, boomerangs, test slippage, just in case code and shotgun surgery
  • F16 – asked to be built for speed but real problem was to escape enemy combat – still very successful 30+ years later
  • scope implies solutions – work out the goals and collaborately work out the scope to meet goals
  • people tell you what they think they need, and by asking them ‘why’ you can identify new implicit goals they have
  • understanding why something is needed, and who needs it, is crucial to evaluating a suggested solution.
  • discuss, prioritise and estimate at goals level for better understanding and reduced effort
  • outside-in design – start with the outputs of the system and investigate why they are needed and how the software can provide them (comes from BDD)
  • one approach is to get developers to write the “I want” part of the storycard
  • when you don’t have control of scope – ask how something is useful, ask for an alternative solution, don’t only look at lowest level, deliver complete features
  • collaboration is valuable – big all team workshops, smaller workshops (three amigos), developers and analysts pairing on tests, developers review tests, informal conversations
  • business analysts are part of the delivery team, not customer representatives
  • right level of detail is picking up a card and saying ‘I’m not quite sure’, it pushes you to have a conversation
  • collaboration – hold introductory meetings, involve stakeholders, work ahead to prepare, developers and testers review stories, prepare only basic examples, overprescribing hinders discussion
  • one of the best ways to check if the requirements are complete is to try to design black-box test cases against them. If we don’t have enough information to design good test cases, we definitely don’t have enough information to build the system.
  • feature examples should be precise (no yes/no answers, use concrete examples), realistic (use real data, get realistic examples from customers), complete (experiment with data combinations, check for alternate ways to test) and easy to understand (don’t explore every combination, look for implied concepts)
  • whenever you see too many examples or very complicated examples in a specification, try to raise the level of abstraction for those descriptions
  • illustrate non-functional requirements – get precice performance requirements, use low-fi prototypes for UI, use the QUPER model, use a checklist for discussions, build a reference example for things that are hard to quantify (such as fun) to compare against
  • good specifications – should be precise and testable, not written as a script, not written as a flow
  • watch out for descriptions of how the system should work, think about what the system should do
  • specifications should not be about software design – not tightly coupled with code, work around technical difficulties, trapped in user interface details
  • specifications should be self explanatory – descriptive title and short paragraph of the goal, understood by others, not over-specified, start basic and then expanded
  • specifications should be focussed – use given-when-then, don’t explicitly detail all the dependencies, put defaults at the technical layer but don’t rely on them
  • define and use an ubiquitous language
  • starting with automation – try a small sample project, plan upfront, don’t postpone or delegate, avoid automating existing manual scripts, gain trust with UI tests
  • managing test automation – don’t treat as second-grade code, describe validation. don’t replicate business logic, automate along system boundaries, don’t check business logic through the UI
  • automating user interfaces – specify interaction at a higher level (logging rather than filling out the login page), check UI functionality with UI specifications, avoid record and playback, setup context in a database
  • test data management – avoid using pre-populated data, use pre-populated reference data, pull prototypes from the database,
  • Bott’s Dott’s are the lane markers on the roads that alert you when you move out of your lane, continuous integration has that function in software, run it with Specification By Example and you have continuous validation
  • reducing unreliability – find most annoying thing and fix it, identify unstable tests, setup dedicated validation environment, automated deployment, test doubles for external systems, multi-stage validation, execute tests in transactions, run quick checks for reference data, wait for events not elapsed time, make asynchronous processing optional, don’t use specification as an end to end validation
  • faster feedback – introduce business time, break long tests into smaller modules, avoid in-memory databases for testing, separate quick and slow tests, keep overnight tests stable, create a current iteration pack, parallelise test runs
  • managing failing tests – sometimes you can’t fix tests – create a known regression failures pack, automatically check disabled tests
  • easy to understand documentation – avoid long specifications, avoid lots of small specifications for a single feature, look for higher level concepts, avoid technical automation concepts
  • consistent documentation – evolve an ubiquitous language, use personas, collaborate on defining language, document building blocks
  • organize for easy access – by stories, functional areas, UI navigation routes, business processes, use tags instead of URLs

Category:

Agile, Book Summary, Testing

Tribes (Book Review & Summary)

After on and off reading of this book for about six months, I finally got around to finishing Tribes by Seth Godin. The book was a gift from my CIO for my involvement in a collaboration initiative at work. The following is my brief review and notes from the book.

Review

The tag line for the book is “we need you to lead us”, and this essentially is the theme of the book. The book reinforces the idea that in this internet age, anybody can (and should) be a leader and anybody can make a living doing things that they love. Furthermore, it highlights that challenging the status quo is okay and that the traditional factory management approaches are dead. It is an easy read and uses a number of examples throughout the book to reinforce the ideas being presented. For the most part, it was common sense to me, but it served as an encouragement and reinforcement to the ideas that I already believe in. This book is best passed on to colleagues who need that push over the edge to challenging the norms in the workplace.

Overall it was an easy, entertaining read and I recommend it to anyone who needs reinforcement or encouragement to lead change.

Summary

Here are my key notes from the book:

  • a tribe is a shared interest and way to communicate
  • everyone is a leader
  • move from being stuck embracing a factory instead of a tribe and acting like managers and employees and not leaders
  • heretics are the new leaders, challenging the status quo
  • leaders have followers, managers have employees
  • leading from the bottom (with a newsletter) – the story of how Seth in the mid-1980′s took a small team with a difficult challenge, and how twice a week he sent a newsletter to all of the employees in the company detailing the team and their good work. Over time a number of people transferred or moonlighted on the project to be be part of the journey, and years later people still talk about the project. The moral of the story is leading, not managing.
  • factories are efficient and stable, but nobody in factories make a difference. Over time, factories have become less stable, nor are they the illusion of a dream job.
  • beware of the unicorn in the balloon factory
  • a remarkable product or service is like a purple cow (brown cows are boring, purple cows are worth mentioning). Why is your team not producing more purple cows?
  • good leaders back off and lead the tribe. This is different to doing nothing. Leadership is a choice to not do anything. Lean in, back off, but don’t do nothing.
  • change needs belief. Change is not made by asking permission, it is made by asking forgiveness later.
  • sheepwalking – hiring obedient people for brain-dead jobs and raising fear to keep them in line. Rather, hire amazing people and give them freedom to do amazing stuff.
  • thermometers reveal something is broken, thermostats are indicators to keep us in sync with the outside world. Thermometers are more valuable than thermostats and very organisation needs at least one.
  • creating a micromovement: 1) publish a manifesto; 2) make it easy for followers to connect with you; 3) make it easy for followers to connect with another; 4) money is not the point; and 5) track progress. The principles are: 1) transparency; 2) movement is bigger than you; 3) grow to thrive; 4) compare to status quo or push in a different direction; 5) exclude outsiders; and 6) build followers up rather than tear others down
  • be willing to be wrong rather than avoiding being wrong, the secret of leadership is to do what you believe in, paint a picture of the future and go there
  • “no” is not the enemy, it is “not yet”, because “not yet” is safe, Change never fails because it is early, it almost always fails because it is too late
  • Reagans secret – listen, value what you hear, and make a decision even if it contradicts the people you are listening to. People want to know they have been heard
  • The Simpsons Movie – Matt Groening resisted product placement, which delayed the project but would have ruined it. Compromise can expedite, but can also ruin.

Category:

Book Summary

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: