Wednesday, November 08, 2006

When you’re positioned for a sprint

There are some projects that run like a well oiled machine. The necessary resources are available, the management fully supports the initiative (i.e. fully funded), all team members understand and faithfully execute their roles, and the planned software system victoriously emerges with tolerable defects.

And then there are projects that are dysfunctional. For example, team members are forced to develop software without receiving any training on the chosen technology, schedules are created with little consideration for the envisioned architecture, and fundamental project management practices are not exercised… There are many case studies (examples available per request) documenting eventual demise of such projects unless a champion rises to the challenge and takes the lead. As an architect, especially if you’re an aspiring architect within your community, you may be provided with an opportunity, or forced, to take the challenge of saving the day.

As an architect with leadership responsibility the first thing you should do is to assess who can help you achieve your mission and who will waste your time. In a typical non-commercial project, there will be people who don’t provide any real value to the progress, but who are protected by management and have to be part of the team. In case of consulting organizations such people are consultants who are temporarily helping a project until their next engagements starts. In government organizations such people may be employees who do a mediocre job and operate on a strict 8 hour mentality versus on the demands of the current lifecycle phase of the project.

The next step is to identify the core features of the system and to ensure that you, as the architect, understand the whole picture. At this point of time you won’t have time to document the as-is and to-be states of the system, but you need to come up with some means to explain the architecture to the core group of people who will help you build the system. The core team needs to have a common understanding of the problem and the path to achieve the objective. The roles and responsibilities must be clearly defined, for example, in a case of a web-based system, the expertise among team members may be broken down by logical tiers (e.g. front end, business logic, persistence).

With core team in place you’ll be functioning as the lubricant during intense integration and string testing periods. You will also be forced to find ways to entertain non-contributors so that they don’t interfere with the execution of the vision. You may be required to defend selected solution for the sake of stability. Request that non-contributors think about the features of the next phase of the product, ask them to investigate some high level problem that the current release experiences, or in a worst case scenario ask them solve the Rubik’s Cube problem.

Living up to the champion status is hard since by now the existence of the project may be in jeopardy. However success can be materialized if you have a vision for near term, able to communicate the selected architecture, and able to identify and motivate a small team of core developers. Don’t forget that the exit criteria for saving the day (i.e. scope of end product and your responsibilities during the sprint) must be established before you begin, otherwise the sprint will turn into a marathon and you shall become ineffective.

No comments:

Blockchain learning path for Enterprise Software colleagues

I wrote this post to document my learning path of blockchain concepts and Ethereum technologies while keeping my “new to blockchain” collea...