Agilizing an organization, a first step

At the company I work for, we have several project roles, namely :

  • System engineers
  • Software engineers
  • Function test engineers
  • I&V

A story that happened to my team in the past has made clear that traditional ways of working need a bit of revision.

One day, adding a new feature was decided by our product management. It was quite a big feature, with a lot of coding, innovative solutions, automating parts of an existing system. In our company, the life-cycle of a feature starts at an implementation proposal-writing phase.  These proposals are actually sets of requirements, coming from our “customers” (we don’t have customers in the traditional meaning of the word, but anyway, it doesn’t really matter. Although I know that documenting requirements is not part of the agile framework, this document is really needed due to the lack of “real” customers). Our system engineer has come up with a proposal, that at some point, stated – the system shall somehow distinguish between different categories of objects.

The document was then handed over to design people. They started to find out how those objects should be distinguished. After several brainstormings, design discussions and debates it was decided that a best solution would be a new GUI element, namely an extended capability-table. However, swapping the old table with the new one took a lot f time. New methods were needed to be introduced to make the table compatible with the old implementation. This automatically generated a two weeks lead time, which also made the management a bit upset.

Finally, the implementation was ready, the increment was passed on to be function tested. Guess what happened; the new table was incompatible with our automated test cases, resulting in a (!)one month lead time. A whole team needed to be allocated to fix the broken test cases. Managers started crying, release date was postponed several times.

So we drew the conclusion that both design and function test should be somehow involved in requirements gathering. In a meeting of just one hour, we decided that:

  1. From time to time a little internal document review (thanks for the term, István) will be held; Designers can ask questions here, share opinions, give voice to doubts etc. Such a way everything written down in the document can be reconsidered before anything is made final. These meetings can generate prototyping and analysis tasks, in order to clear technical doubts.
  2. Component prototypes will be created by a couple or more designers. In order this to be successful system people will attend standup meetings. Short discussions will be held; system can answer “daily questions”
  3. There will be created a prioritized backlog for prototypes. The backlog will be administered by product owners (=system people), and will be reorganized in every two weeks.
  4. Function testers will also be involved in document elaboration. They will create automated test cases and stress tests for the above mentioned prototypes.
  5. Design people will be given the opportunity to take part in splitting work items into user stories.

The next implementation proposal will be written based on the action points above. We expect that more tricky details will be uncovered, making design and testing more fluent. We’ll see…

Advertisements

Author: tamasgyorfi

Senior software engineer, certified enterprise architect and certified Scrum master. Feel free to connect on Twitter: @tamasgyorfi

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s