Role of Software Architect in Agile Projects

Role of Software Architect in Agile Projects

One of the biggest misconceptions about Agile is that architecture is not required in the Agile development. ‘We‘re Agile; we don’t need architecture’–is something that everybody involved in Agile has heard at least once.

Let’s start by establishing a common understanding of what the software architecture is, to which everyone can agree. The definition of architecture is quite broad, and the roles and responsibilities of software architects vary dramatically from company to company.

Here is how Martin Fowler identifies architecture in Patterns of Enterprise Application Architecture:

“Architecture” is a term that lots of people try to define, with little agreement. There are two common elements: one is the highest-level breakdown of a system into its parts; the other–decisions that are hard to change.”

I find that we all can agree on those two common elements. Do we need the highest-level system break down? Absolutely. Do we need huge documents and long design stages? No. Agile is not against the architecture–it’s against useless, bulky documentation that nobody reads anyway.

From the perspective of change, the role of architecture in Agile development becomes quite clear – A good architecture is responsive and will support agility; a poor architecture will resist it and reduce it. And, since one of the benefits of adopting Agile is a better response to changes in the requirements, it’s obvious that flexible and extendable architecture is a key to this.

The biggest issue that I’ve noticed is the very thin line between architectural design and software design. I’ve seen companies where the different implementations of the following practice were used: Architects created design documentation and developers were responsible for writing the code. This introduced a myriad of problems, starting with developers feeling that they were not fully trusted. This also gave developers an excuse not to really think about the design. ‘We’re just coders, not responsible for the design and we do only what we are told to do.’ is a common attitude that I have witnessed. In Agile, the developer is responsible for the code he writes (and unit tests) as well as the design since nobody else will provide him with it.

Ideally, the high-level software architecture is completed before coding starts. And I really have to be careful here – completed doesn’t mean written in stone; it can change, but with an understanding “this is the best of what we know right now.” This doesn’t necessarily include a database design or class diagram, and the level of details really depends on the approach you will be taking moving forward. I found that for certain systems the Domain Drive Design (DDD) is extremely useful and has made my life far easier. Therefore, I like to have a domain model and a basic set of domain classes and their relations defined, but not to the level of methods and attributes.

Personally, I prefer projects to have a design stage; this is when the high-level business domain model and user stories are created. At this stage the main architectural decisions are made – the technology that will be used, the database server, the application type (for example, Mobile, rich client, or service), the architecture style (client server, layered architecture, SOA) is selected, and the architectural frame that will be applied is selected as well. The document created during this phase is not solely architectural effort, it is a collaborative effort of business analysts, developers, and network administrators. The output of this design stage is not only a high-level architectural document. (This is not an attempt to make fixed predictions of the future or create a detailed software design upfront as this approach places all the significant decisions at the point of least knowledge in a project’s lifecycle). This is simply a way of getting and sharing the common understanding of the system we are all about to develop.

This is an excerpt from the forthcoming book, The Art of Being Agile.

[Image Courtesy: Flickr/Helix/Philip Gunkel]

How Measuring Velocity Helps in Your Agile Journey

How Measuring Velocity Helps in Your Agile Journey

Measuring velocity is a useful way of determining how long an agile project will take to complete, by providing a rough estimate of the amount of work the team can complete in a sprint.  It is necessary to keep in mind, however, that as insightful as knowing your team’s velocity is, velocity is not a true measure of your product’s development.

This post will discuss what velocity is and the reason why we measure it, and why management is interested in higher versus lower velocity.

Velocity Defined

Velocity, in terms of agile product management, is a metric that provides insight into approximately how much work a given team can complete in a sprint.  Measuring velocity uses information from a completed sprint, so if your team is approaching its first sprint, you must know how many people will be involved in the project, the maximum amount of work each person can complete, and the total number of workdays in the sprint, in order to calculate the velocity.

Calculating velocity involves units of work that can be defined as hours or story points – a metric capturing the complexity of implementing a story – for example, and tasks.  Velocity is calculated by adding up the difficulty metric of every backlog task, such as stories, completed by the team in a given sprint with the units of work for those tasks.  This provides the velocity in terms of units of work per sprint.

Why Measure Velocity?

Velocity provides an estimate of how much work your team, specifically, can complete in a given sprint.  As velocity is calculated using the work of previous sprints and if everything remains constant – such as the same people are involved and the tasks are relatively of the same nature – then velocity is consistent.  If the team had a velocity of 30 story points per sprint for previous software development projects, then it can be expected that, all else constant, the team will have a velocity of 30 story points per sprint in the next software development project.

Velocity is useful in estimating the approximate length that a project will take, as well.  If the project at hand has 120 story points’ worth of stories, and previous sprints show that the team has a velocity of 30 story points per sprint, then it can be expected that the team will complete the present project in four sprints.

Higher Velocity Versus Lower Velocity

As velocity signifies an agile team’s productivity – the velocity value indicates that either the team completed fewer high-difficulty stories, or they completed many stories of lower difficulty – it is more desirable for a team to have a higher velocity than a lower one.  A higher velocity would indicate that the team is capable of completing more stories or high-difficulty stories, which translate into more progress towards the project.

It is worth noting, though, that when teams are measuring their velocity at the start of a project, the velocity value will not be as accurate as it will be for later sprints.  An underestimation when initially measuring velocity can result in a higher velocity later on in the project.  Similarly, an overestimation in initially measuring the velocity will lead to a lower velocity later on in the project, as the velocity is adjusted with each completed sprint.  As such, the velocity value that is calculated later on in a project may not accurately reflect the team’s productivity; their productivity could have remained constant, yet the change in velocity value may be due to an under or overestimation.

Velocity Is Not a True Measure of Product Development

As useful as measuring velocity is, an agile team should not rely on their velocity to indicate the progress of their product’s development.  The velocity is measured based on each sprint, and with each new sprint, new product features’ information is accumulated and added; this changes the stories and story points associated with the next sprint, so the previous sprint’s velocity is not necessarily indicative of the team’s work in the next sprint.  Many new features may have to be added or changed in the next sprint, so the nearly completed product of the previous sprint may actually be 40% completed, given the previous sprint’s feedback.  Even though the team had a high velocity in the previous sprint, product feedback necessitated even more work before the product can be deemed complete.

{Photo courtesy: Flickr/Jan-Hendrik Palic}

How Can You Get More Effective with DevOps?

Here’s the excerpt of my recent article published in Better Software Magazine, :

The promise of DevOps is to provide a basis of collaboration between organizations and IT that produces superior customer value.

One of the most recent changes in the operations and delivery surrounding IT has been a new awareness of how critical sup- port for ongoing operations is, and how the value chain should continue to improve for the various businesses that IT sup- ports. For large and fair-sized corporations, where the core business is anything but IT, popular opinion suggests that IT is perceived to consume company profits—essentially, a cost center. This has led to a high level of scrutiny in recent years, especially with tighter budgets and shrinking profits. The need for tight control of expenditures in IT development and support to keep the network running smoothly is a growing concern for the CIO and CFO. In effect, this has turned into a struggle between the need to main- tain tight operations with minimum expenditures and resources while attempting to maximize support and continuing to produce results. …

Download the Better Software Magazine’s July/August 2014 Edition here to read the full article.

How to Be a Stellar Product Owner

Here’s the repost of my recent post on

As we get into the routine of releases and sprints, over time the Scrum team establishes its work pattern, and the product owner (PO) becomes more familiar with not only the team but with methods for developing the product build with agility. As we move into sprint after sprint, daily stand-ups, planning, review, and retrospective sessions become second nature for the team. During this process, the PO may feel overwhelmed by the demands of involvement with the team, as well as the demands of external priorities. Some POs may lose their focus on the team as those external priorities shift. To address this and a few other factors that can affect the transition from being an average PO to being a stellar PO, I’ve listed some traits that can help a PO move in that direction.

A stellar PO makes himself or herself available to the team.

Product ownership is more than just a minor commitment — active participation in team gatherings is essential. A stellar PO must also commit to assisting with the resolution of various impediments affecting the team and with keeping product development on track, which requires more than a fair share of commitment.

Product ownership may be not a full-time job, but it needs sincere, dedicated attention from the PO so that the team gets queries answered and clarified, so they can keep development continuous, without any hiccups.

While the PO makes sure that his or her availability is active and ongoing for the team, the team should make sure that they respect the PO’s time, making productive use of everyone’s time during various Scrum ceremonies and activities.

A stellar PO is knowledgeable about the product being developed.

One of the key factors that every PO should know is the organization’s end-user market. Without that knowledge, any PO could unintentionally derail the team and lead them in the wrong direction — and on toward failure. The PO must be well versed in each and every end-user requirement.

From the team’s perspective, the PO is a powerful and resourceful representative for the business (as it pertains to a specific product within a business unit). As such, a stellar PO should have access to all pertinent information and should have full authority to guide product decisions in the right manner through the various Scrum ceremonies.

The PO represents the business and speaks on behalf of the business — any conflicts or issues encountered during development must be resolved by a single voice in the favor of customer value and end-user benefit.

A stellar PO is empowered.

With two-week sprint cycles, the entire duration is crucial for completing, testing, and potentially shipping the number of stories selected by the team. Since time is of the essence here, it becomes absolutely essential for the PO to respond in a timely manner to all requests for information or clarification that are sent his way by the team. Promptness, being on top of things, and fighting fires for the team is the key to the success of the project.

POs are direct business representatives (at least that’s the expectation), and it is expected that part of the PO’s role is to provide ready access to decision makers or influencers. In the absence of such access, crucial development decisions can be delayed and progress slows down — or comes to a halt — as the team struggles with issues that the PO should be able to easily manage. The result is incomplete stories and an unsatisfactory sprint outcome for the end user.

One of the strong traits that a stellar PO exhibits is acting as an advocate for the team. Teams that receive essential and accurate product direction and support build a higher-value business product. The stellar PO should take every opportunity to demonstrate advocacy for the team.


If you think of the product development cycle as a train, the team is part of the engine and the PO acts as its conductor. As developers move the process forward (acting much like an engine), they improve efficiency with every effort applied to delivery, and they help move the product as directed by their conductor, the PO, according to the defined and accepted stories and requirements. The conductor keeps the product train on track so it reaches every determined station (sprint completion) with the allotted resources and within the set time frames. Both the conductor and the engine must work together to get the product train to the right station with the right requirements and resources, in one piece and on time — each representing half of the equation toward reaching the solution. The PO and the team are core partners on this “journey,” and their profit is ultimately measured by building a high-value business product for their customers.

Lean Building: Understanding Waste and Managing It with Agile

Here’s the excerpt of my recent post on

Within the context of product development and manufacturing, Lean management is essentially an efficient means of controlling production costs and maximizing profit over the product life cycle while avoiding and reducing defects and scrap (wasted effort, time, and resources). Waste typically occurs in the form of excess inventory, production, resources, or processes. This is valid for the manufacturing industry but is applicable to other industries as well, though the terminology may change.

There are eight areas of waste defined in Lean management:

  1. Transport: Moving people, products, and information
  2. Overproduction: Producing more than is immediately required
  3. Waiting: For parts, information, instructions, resources, and equipment
  4. Inventory: Warehousing parts, pieces, and documentation ahead of requirements
  5. Skills: Underusing staff capabilities or delegating tasks beyond scope and training…

To read more, please go to >>

Pin It on Pinterest