Agile development and UML

In case of agile development, we usually don’t run into hundreds of lines of documentation, with detailed diagrams, architecture proposals etc. This is good for several reasons; developers can use their creativity in order to materialize requirements. This way, people won’t fall into the pitfall of blindly following someone’s vision either.

However, UML may become in handy at feature development. With just a small investment (as low as the price of a whiteboard) a team can boost their productivity. This is how: promote a whitheboard as “design board”. The design board has no other role, than to store the current architecture of the feature under development. It, of course,  supposes that each and every team member updates the board whenever they make a change to the current state.

One might argue that there are a lot of software tools out there, why not use those? Well, the answer is simple; people are lazy (and forgetful, in the same time). Even if the UML diagram is stored somewhere everyone has access to, they won’t open it, let alone update it. They simply forget it, becouse the thing is not in front of their eyes all day long. However, if it is present materially, people actually tend to update it on a regular basis (also, daily standup meeting is a really good period to remaind everyone to do so, in the case they somehow forget it). The diagram doesn’t have to be that detailed. It’s perfectly enough if it contains the classes and interfaces, associations (uses, implements, extends …) and main methods.

How does this help increase velocity? Simple. People don’t have to randomly open different classes in order to find the right one to place some new code in. They just take a look at the board and know immediately how classes are related, which is the right one for the new logic. They also don’t have to remember all the class names and the relationships between the different components. Planning meetings (along with task breakdowns) will also get shorter. It eliminates the phrases that start with the infamous “well, I guess…” stuff; people will talk about facts not beliefs. Less stress, less time spent on arguing.

Advertisements

Author: tamasgyorfi

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

1 thought on “Agile development and UML”

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