Aug
24
By: Giora Morein
8/24/08 5:27 pm CDT

Event: Agile2008, August 2008
Location: Toronto, Canada
Presenters: Giora Morein and George Schlitz

George Schlitz and I presented at the recent Agile2008 conference in Toronto on how to leverage Ambassador Models to enable highly effective distributed teams.

Download the Presentation



Jul
24
By: Brian Bozzuto
7/24/08 8:07 pm CDT

The other day I was working with a product owner, let’s call him John, for a team that had been using Scrum for about 10 weeks and was becoming proficient with the framework. Compared to some of his peer teams within the larger program, they were doing quite well. They were effectively planning iterations, managing a backlog and consistently increasing velocity. Everything was looking good as we were putting together the agenda for iteration planning the next day, when John asked if we really needed to set aside time to do a retrospective.

The team is working effectively and seems to have a good grasp on what’s going on. We have a lot of work to complete, he explained. Wouldn’t it make sense to use the time simply to start the iteration?

I can’t begrudge John for his sincere question, and I know that I have personally fallen into this trap myself. While eliminating regular retrospectives is a clear violation of the rules of scrum, the criteria for an effective retrospective is more than simply holding a meeting to discuss “what went well, what didn’t go well, and what can we improve”. I can think of numerous such exercises that were unable to penetrate a superficial level excusing challenges as unique instances that are not indicative or larger patterns and concluding that things are running pretty well, much as they have been for a while.

In fact, I learned the real value of retrospection before even becoming Scrum Master. I had just started a job working as a BA & PM for a financial services firm and was teamed up with a few senior developers to build a new application. I had just joined the company and was careful to understand the dynamic of the team I was working with. I reached out to the business partners to understand what they were trying to do and we frequently checked in with the end users to get feedback as well. While I didn’t appreciate it at the time, my uncertainty in the domain led to frequent inspections and adaptions. Fortunately, the project was a great success and management funded a follow up project to further improve the feature set. They gave us more time and kept the original team together. I was even promoted to a “Senior Analyst”. Expectations were very high; that’s when the problems began.

In hindsight, I can see that we were intimidated by the amount of work. Consequently, we quickly jumped into the task at hand without discussing closely with the business unit. I naively felt we understood the business domain based on our prior successes; after all, I was the veteran team member who had led us to success the first time. We assumed the team’s dynamic would be consistent and our business domain was unchanged. Small, but important, requirements were missed, people began arguing over features and our objective looked farther and farther away. Looking back I can’t think of an huge mistake we made, rather it was a number of small things adding up over time. I didn’t appreciate the senior developer was hoping to leverage this second project into a promotion, and as such he was too eager to demonstrate leadership that at times was seen as bullying. I failed to see we were now offering premium capabilities that brought in better premiums but needed to be customized. Indeed it was a steady stream of small bumps like these that wore the team down. The most frustrating part was that we had been so successful the first time. In our minds, it was the same team working in the same domain; why was the second time so different?

In the first project, we were a new team and I specifically was new to the business area. As such, we spent a great deal of time trying to understand both what the business needed as well as how the project team was interacting. This level of inquiry and adaption revealed various insights that helped the project succeed. Unfortunately in the second project, we assumed it was those specific insights which resulted in the successful project and not the actual process of inquiry and adoption. Closed to inquiry, we were mentally attached to a set of rapidly expiring assumptions. Ironically, it was success of the first project that was most responsible for the failure of the second one.

So how do we avoid these situations? What do we say to those people like John who earnestly ask about simply avoiding retrospection? To his credit, John was much more aware and open about his perspective than many of us. Most of the time, we don’t say we’re going to stop reflecting on what we do. We simply close our minds, stop looking for patterns and go about however we are already comfortable working. Indeed, this is one of the values of scrum: it forces the team to go through this ceremony on a regular basis.

But more than the consistency of the ceremony, I believe it is the mindset of the team that matters most. It is patently obvious there is no such thing as a perfect team. As such, whether a team has formally embraced Scrum, Agile or no such framework, we are all on a journey. There is no real end to this endeavor where our execution will be flawless, or even “good enough” that we can stop reflecting upon how we go about the nature of our work. Even if such a “perfect” team were to exist, the exponential increases in computer processing power and relentless stream of new software tools to use it would render the carefully calibrated balance of such a team obsolete in no time. We must avoid the trap of assuming there is a best way to do things and look at our endeavors simply more as a journey. As with any profound journey, its how you get there that matters more than the destination.



May
31
By: Alex Singh
5/31/08 8:58 pm CDT

Abraham Lincoln used to ask a riddle: “If you call a tail a leg, how many legs does a dog have?”

Answer: Four, because calling it a leg doesn’t make it a leg.

more »



May
24
By: George Schlitz
5/24/08 1:20 pm CDT

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 »



May
18
By: Giora Morein
5/18/08 11:26 am CDT

Event: Microsoft Effective Agile Open House
Location: Herziliya, Israel
Presenter: Giora Morein

I would like to thank all who participated in the Microsoft Effective Agile Open House event today in Herziliya in Israel. Here are the presentations.

Agile Kickstart (pdf)

Effective Distributed Agile Teams (pdf)

 



May
18
By: Mike Dwyer
5/18/08 8:55 am CDT

This post is an excerpt from an on-going conversation at http://tech.groups.yahoo.com/group/agileleadership.

I have been asking for comments and perspectives about leadership, traditional management, Agile Leadership and so on.  The thread is well received and i wanted to bring this element to this community as it begins to address places where all sides seem to converge.

Glen Alleman wrote:

I’ve started speaking of non-agile project management is bad (or poor) project management, since responding to the emerging situation is part of good project management - as defined in PMBOK. Therefore not responding is bad. I’ve started using “conventional” to distinguish the processes used in many locations to great success. Agile and Conventional are certainly different. Non-agile is non-functional and therefore a nonstarter for success.

Ron Jeffries responded:

Would that more people believed that.

From my perspective;

I think Agilists differ from conventionalists in that they put Respect and Leadership over Rank and Management, and make this distinction transparent.

Perhaps one of the key attributes of an Agile Leadership environment is the passing of the leadership position to the person the team trusts most to address the issue. This fluidity, seen in ‘self organization’, pair programming, and most dynamically in planning sessions seems to become the bonding agent of the team.

Now does this translate into organizations. I think the answer is yes, but the result is a new management process that goes to the top of the management and stakeholder organization. We have mentioned “Corps Business” and some of us have delved into OODA, the three block war, and I have seen some organizations make steps toward this.

What I think I am seeing is the trust component of leadership and followership extend into the management of the organization and manifest itself in Management retain Control of the plan and teams of people at the lowest level in the organization take over Command of the situation. The Middle part of the organization exists to serve both those above and those below by clearly defining, the mission statement and the commander’s intent; advising those above on the capabilities and limitations in meeting those statements and intents and removing the impediments facing the teams as well as shepherding the solutions to the needs and requests of the team as they encounter unpredicted, emergent challenges.



Apr
26
By: Alex Singh
4/26/08 11:54 am CDT

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.

more »