One of my favorite teachers in college was a former managerial consultant and our class enjoyed being regaled with stories of her former clients - a veritable who’s who of major companies - and the challenges they faced. I recall one lecture when she was telling us about reports and communications and how you need to understand the psychological impact they may have on an organization. She was working with a major department store in the early 90’s when the organization was in a steep decline. more »

Recent events allowed me to catch up on light reading and I found myself going through “Sway - The Irreresitable Pull of Irrational Behavior” by Ori and Rom Brafman. The book is a generally enjoyable light read, but it delved into one topic I found very fascinating: irrational loss aversion. more »

Of all the virtues within Agile software development, none are more important than the numerous means of receiving feedback layered into the entire Agile life cycle. The team shares a quick checkpoint at the daily stand up, the scrum master fosters earnest discussions of team effectiveness with periodic retrospectives, project stakeholders can clearly see and interact with potentially shippable code at regularly occurring show and tells and ultimately the entire community can offer feedback due to frequent releases. This is a powerful cycle as early and frequent feedback can help move a product in a positive direction, keep a team excited, and ultimately lead to more business value. But this entire structure is predicated upon the team receiving valuable and relevant feedback. Having such a structure is not enough, we need to make sure the quality of our feedback loops is sufficient too. more »

There are so many well-thought out software development (SD) methods. They are laid out beautifully on paper- diagrams of traceability of activities and artifacts to take ideas from users’ minds all the way through product implementation and operation. Together with some templates, guidance, tools, training, and packaged together in a professional way, a software development method is born. more »

I recently got invited back, for the third time, by a client in the “Leisure, Travel & Tourism” industry to develop applications for their Cruise business. I play the role of an Engagement Manager and Business Demand Manager, whereby I am responsible for business idea harvesting and business idea vetting for the client

In the past two years, this client has moved from a crappy Agile implementation to doing Agile the right way to implementing a lean software development system. They have taken the concept of smaller batches, removal of waste, and continuous flow of value to heart.
more »

I recently worked at an insurance company (let’s call it Freesurance) that had mandated a “glide plane” process to bring a semblance of regularity to the chaotic development practices in place. All projects were to pass through specified stages of the glide plane at specified times. Glide planes were staggered to start every month.

Employees were mandated to enter all tickets (work requests, enhancements, and bug fixes) into a requirement-tracking tool. All tickets were to track through each of the following phases.

• New: All new work requests (tickets) should be entered into the requirement-tracking tool by the business analysts or by the development teams. Tickets must be entered at least 91 days before a scheduled monthly release.
• Acknowledged: A service level agreement (SLA) mandated that the business must acknowledge tickets within 7 days of receipt of the ticket – 84 days prior to release. This 7-day period was used to triage the tickets to remove duplicates, close tickets if no action was going to be undertaken, and to prioritize the items.
• Accepted: The IS department is tasked by the business to analyze and estimate the tickets — target 63 days prior to release.
• Business Requirements: The business analysts were required to complete the business requirements 42 days prior to release.
• Committed: IS would commit to the tickets, 28 days prior to release, that it thought it could complete — create functional specifications, construct, unit test, and build within the release dates.
• IN/OUT List: Final date to decide whether tickets are going to be included in this release or not.
• Constructed: IS completes coding, unit testing, and delivering final build 14 days prior to release.
• Resolved: Business analysts complete all testing 7 days prior to release.
• Closed: Code merged into the production environment (”going live”) on implementation day; Business signs-off on the release within 5 days of implementation. more »

My experience is predominantly within large, Fortune-class companies.  It is possible that many of my observations apply on to organizations that have grown to tens of thousands of people over many, many years.  I do not know if many of the same ailments apply to smaller companies – although with the exception of the odd start-up, I suspect that the same commitment-issues plague us all.  more »