February 4, 2012

Posts Comments

BigVisible Blog

Determining Actors and Defining Back-end Stories

April 26, 2008 By Alex Singh 1 Comment

Last year I was involved in rescuing the delivery of an Educational Loan Servicing system for a couple of state education departments (the trials and tribulations in another blog). Like a number of projects in the Financial, Insurance, and Investment Banking industry, this project involved a significant number of back-end batch processes.

There were a few problems that the teams faced when attempting to discover the stories:

  1. There was minimal user interface and it wasn’t readily apparent who the users were for these back-office applications.
  2. The team was at a loss on how to define the stories. Most of the stories by themselves provided no benefit — determining business value was difficult.

Let’s tackle these two separately.

[Read more...]

Filed Under: Agile Coaching Tagged With: ,

Hiring the right people

April 10, 2008 By Alex Singh 1 Comment

General Colin Powell in his Leadership Primer says that:

“Organization doesn’t really accomplish anything. Plans don’t accomplish anything, either. Theories of management don’t much matter. Endeavors succeed or fail because of the people involved. Only by attracting the best people will you accomplish great deeds.”

So, how do you attract and choose the best people to work in your organization? What are the qualities that you look for when hiring people – is it the length of their resume, their past positions, their degrees or where they obtained them? Is it their familiarity and expertise with the specific technology or domain that the company needs at the moment?

[Read more...]

Filed Under: Agile Adoption Tagged With: , ,

Instilling a Sense of Urgency

April 7, 2008 By Alex Singh Leave a Comment

When people ask for “a sense of urgency” or “ownership” what they are really saying is “show me that you care about delivering this as much as I do”. Here are a few suggestions in an Agile context in no particular order of importance:

  • Schedule the end of iteration demonstrations for the next 6-12 months – highly visible deadlines prevent teams from over-engineering solutions.
  • Hold team members collectively accountable for team performance and for fulfilling job responsibilities. When things do not get delivered it is the team that has failed – freeloaders or those who are completely unsuited for the job will usually not be tolerated by high performing teams for long.
  • A team’s performance is limited by the least invested individual. Such people dampen everyone’s morale and it is essential to quickly counteract people who habitually over-promise, make excuses, reject responsibility, complain, and lack commitment. While some skepticism up-front is healthy, perpetual grousing is not. To counter this, it is essential to clearly define and communicate behavioral expectations up-front and the consequences of not changing (if any).
  • Clearly define and communicate expectations for decision-making including span of control and scope. This is to ensure that the team is not waiting around to be told what to do next.
  • Require teams to develop corrective action plans for performance that is not meeting goals.
  • Set a good example by promptly responding to questions, concerns, and escalated problems. Clearly communicate time frames for follow-up and consistently follow-up within these time frames.
  • Help team members separate facts from emotional baggage.
  • Recognize individuals and teams that respond with urgency.
  • Discuss Chris Avery’s Responsibility Process Model or Roger Conners’ Oz Principle early in the transition process and refer to either at appropriate junctures.

Filed Under: Agile Adoption, Agile Coaching Tagged With: , , , , ,

Lean software development at current client

April 5, 2008 By Alex Singh 1 Comment

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.
[Read more...]

Filed Under: Product Development Tagged With:

Breaking Agile Rules!

April 5, 2008 By Alex Singh Leave a Comment

I recently encountered a situation where we had three development teams working on the same product. Two separate clients that were supposed to act as one had jointly financed the project and were planning to individually sell it to educational institutions in their respective states (Texas and New Mexico). Needless to say the goal of acting as one never happened and conflicting requirements became the norm. Conversations were not working as the clients could not agree amongst themselves; prioritization wasn’t working as the clients had different short-term needs and were afraid that the other client’s needs would be given preference.

[Read more...]

Filed Under: Agile Coaching

RUP isn’t agile but some of its principles are worthwhile

April 5, 2008 By Alex Singh 5 Comments

Why RUP isn’t Agile?

I work with a number of people who come from a RUP background and who claim that RUP is Agile because RUP calls for iterative development. While a cursory reading of RUP literature may show that the RUP framework doesn’t really mandate anything — it is a framework not a process — and leaves things up to the team and organization, it’s spirit couldn’t be further from Agile. I just have a hard time reconciling some of  the ideas behind RUP to Agile values and principles

[Read more...]

Filed Under: Agile Adoption, Agile Coaching Tagged With: , ,

Glide Plane and Personal Responsibility

April 4, 2008 By Alex Singh Leave a Comment

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. [Read more...]

Pages: 1 2

Filed Under: Product Development
« Older Posts