So what should an ‘agile architect’ be doing?

“So many architects walk around with the world on their shoulders. The responsibility of figuring out all this ‘stuff’ is supposedly taxing. Screw that… You are a creator… Go create…”

Agile Architect in his natural habitat.jpg

“An agile architect in his natural habitat dancing in a field of complexity…”

I recently wrote a blog on whether software architecture matters. It was a quick stream of consciousness hacked out in record time like most of my blog entries (probably riddled with grammatical errors and spelling mistakes). And like many of my blog entries it got a few muted grumbles from my extended professional network, especially from those that are ‘architects’ by trade.

The one thing that all of the grumbles had in common was the question of what I think a so called ‘agile architect’ should  be doing? This because I suggested that most of the design decisions should sit with the team. Not wanting to disappoint my somewhat less than usually chirpy ‘architect’ counterparts here is my list of things of things I believe we should be doing collectively:

1. Be part of the the development team

You are there to inform, motivate and influence the team without expending social capital by forcing your decisions. Being removed from the actual development effort and simply flinging architectural documents (that probably don’t reflect actual system code) at devs is not good enough anymore.

2. Adapt to the team’s way of working, not the other way around

In order to build high performance teams you need to create space for autonomy, mastery and purpose. The autonomy boundary can be constrained, but each team’s sweet spot in terms of their way of working will differ slightly. Standardizing your approach will simply lack the flexibility and variability that modern teams need and require.

3. Your job is to accelerate the project not to slow it down

Change priorities, trash requirements, architecture spike yourself to death. Whatever you do don’t stop the flow of value creation. There are many things that need to happen in projects. Many of those don’t need to stand still while perfect understanding (or consensus) is sought. Too many ‘architects’ plant their heels into the ground demanding big analysis when uncertainty is encountered. By nature they are top down thinkers that want to completely disseminate and understand a problem before making decisions. This however introduces a ton of friction into the development process. Defer as much decision making for as late as possible, outsource as much risk to others, focus on the really scary parts that can blow your design but don’t become another blocker.

4. Your job is preliminary about communication, do it often and early

It is really hard to create a shared understanding in the minds of everyone involved in a project (business, tech and design). Add different personalities, skills and backgrounds and it gets even harder. Heck even involving too many people or the wrong people too early is enough to explode the number of communication paths you have to contend with. So be transparent and open at all times. Trash complicated diagram standards and do everything in your power to drive context and understanding. Simplify and re-frame things over-and-over. Repeat this relentlessly until a semi coherent common understanding is reached and people start taking initiative on their own. Once that happens simply curate and make sure it is correct being careful not to trample and people’s attempt at contextualization.

5. Focus on the essence of the problem, the simpler the better

Stop creating artifacts, documents and stuff that nobody can contextualize. Even if you have to explain things over-and-over again this will refine the concept in your head and provide extra insights. Look at initiatives like C4 diagrams to get your drawings more in line with the actual thing being built.

6. Test your architecture

POCs or Architecture spikes are single-handedly the best way to validate parts of your architecture. But in too many organizations this is seen as a waste of time and money. Change the way you fund projects and cater for this activity. While you are at it always add slack for testing the non-functionals of your architecture (scalability, performance and robustness).

7. Question standards

Corporations are rife with cargo-cults that never question why they do the things that they do. “It is just the way it is done, or the standard”, is a common refrain. This is such a bullshit attitude that guarantees sub-optimal solutions. Be ruthless in questioning ordained “standards”. Especially if a “standard” is merely written down glorified opinion piece that has never been tested and validated.

8. Promote agile practices in other areas of the business

Unfortunately most organizations only embrace agility in their delivery teams. It is your job to promote lean and agile practices in the supporting functions that support the team.

9. The most important thing: Don’t take yourself so seriously

So many architects walk around with the world on their shoulders. The responsibility of figuring out all this “stuff” is supposedly taxing. Screw that… You are a creator… Go create great things with your teams, have fun with them and enjoy it. Stop taking yourself so seriously.

 

Advertisements

Cultivating a cause worth believing in for software teams…

“By design they care gravely about where they plow their trade and by virtue of their idealistic natures they are looking for something that they can believe in.”

The lonely road of vision of leadership

“In order to land the best talent in industry, you need a purpose or an idea that people can rally behind. More importantly it has to be real and speak to the hearts and minds of people on whatever path they may be on.”

Anybody that has tried to build a software development competency will tell you that it is really hard to hire well. The reason for this is due to the fact that one is searching for a very unique type of individual. Individuals that are extremely idealistic in nature,  can think critically and are pragmatic when needed. Yet the same individuals have to have a healthy dose of creativity and artistry allowing for abstract thought and non linear thinking.

Of course there are certain organizations, individuals and teams that don’t care about culture. For them its easy to hire since it essentially just becomes a numbers game. A rough checkbox marking exercise where you just find people that kinda look right and throw money at them. But I am not referring to these toxic cultures.

I am rather talking about those organizations that don’t view delivery as mere ‘resources’. Those organization that realize that the culture one builds is the thing that actually creates whatever outcome you are looking for.

“If they wanted just another ‘job’ they could have it a few days of interviewing.”

In healthy organization such as this, to find the aforementioned individuals can be excruciatingly hard and time consuming. They regularly get approached by recruiters with offers and they have a veritable pick of a wide range of opportunities. If they wanted just another ‘job’ they could have it a few days of interviewing. But for these individuals it not just about another ‘job’. By design they care gravely about where they plow their trade and by virtue of their idealistic natures they are looking for something that they can believe in.

The right individuals don’t see their careers as just a ‘job’, but rather a calling. They are passionate about the craft that they have spent years honing and want to use it to build great things. They want to be trusted and empowered to use their craft and certainly don’t want others to dictate to them how they should be using their craft.

Understand that these people are not stupid. They are hyper intelligent, well educated and ruthlessly clinical in their thinking. This means that they can smell bulls@#$ a mile away.

“Lots of corporations think that they can attract a lure talent by talking a big game, manufacturing unauthentic ideals/values/visions and engaging in imitation innovation to show ‘coolness’.”

Lots of corporations think that they can attract a lure talent by talking a big game, manufacturing unauthentic ideals/values/visions and engaging in imitation innovation to show ‘coolness’. This type of behavior will only fool people for so long if it is not truly part of the organization’s DNA.

In order to really land the best talent in the industry, you need a purpose or an idea that people can rally behind. And more importantly it has to be real and speak to the hearts and minds of people. This vision that you share with people has to have integrity or it will simply fail.

Secondly, behind this vision should sit a leader that is not just a salesman but who cares (and regularly shows) a responsibility for the careers (and by extension the lives) of the people that choose to follow the vision.

Now the natural reaction for people outside of technology is to view such views with a healthy dose of resistance. Statements around technology not being unique or that everyone should be treated the same way would be common. And they are right, everyone should be treated the same. But that treatment should be more in-line with the way technology wants to be treated.

The corporate cargo cultures frequently miss this point. What technologists are after is an environment that has moved on from the traditional command-and-dictate structures of the industrial era. A flat networked styled organization in-line with the modern knowledge economy. And since most white collar workers are also participants in the knowledge economy, they likely seek the same goals of autonomy, mastery and purpose that the geeks wane about all the time.

Whether we want to admit it or not, software has and continues to drive the modern industrial revolution. It is therefore at the forefront of shaping what modern organizations culture should and could be. So instead of taking a defensive position and mounting the delicate snowflake attack, realize that your delivery team culture is a testing ground for your organization’s future culture. The really interesting thing is that if you pass the test with hyper-critical geeks, it means that your cultural values will undoubtedly work well in all areas of your organization.

“Having a cause that you believe in as a leader is not enough. In order to galvanize and motivate others you have to translate that belief into something tangible and meaningful to them.”

But how to make it real? Having a cause that you believe in as a leader is not enough. In order to galvanize and motivate others you have to translate that belief into something tangible and meaningful to them. Everybody works for their own selfish reasons and unless people can clearly see what it is that is in it for them, they will not care. If you are honest and sincere, and can successfully translate your vision in a tangible way to others then you have the makings of a movement.

And there are warning signs. For example if your top technologists and leaders are continually in debates about how to achieve something instead of focusing on what. This is a tell tale sign that the cultural foundations are weak and are at risk of failure.

Daniel H. Pink is a renowned author on this subject matter and certainly his book Drive should be read by every ‘leader’ in business. But to end this somewhat long article I think it is appropriate to borrow some of his swag with a quote.

“While complying can be an effective strategy for physical survival, it’s a lousy one for personal fulfillment. Living a satisfying life requires more than simply meeting the demands of those in control. Yet in our offices and our classrooms we have way too much compliance and way too little engagement. The former might get you through the day, but only the latter will get you through the night.”

Does software architecture matter?

“This means that no distinction should exist between architecture and the act of coding. It is an activity that should be a shared concern of an autonomous team building a system collaboratively.”

fba7038527ae2d58a26a984c58e6e95d.jpg

The strangest version of this functional role is when someone that does not come from a technical background starts making proclamations about architecture…

One of the strangest functional roles that exist in corporate software development environments is that of the “software architect”. The very term evokes images of a senior engineer that has by virtue of his or her experience mastered his or her craft so well that they need not partake in trivialities such as writing code anymore.

Just like the architect in the movie ‘The Matrix’, these individuals can simply sit and make high brow proclamations about how software should be built. Afterwards they can marvel at the genius of what they have supposedly conceptualized while skeptically bemoaning the apparent failures on part of the people that had to execute on their vision.

The biggest problem with having these ivory tower styled architects is that if you are going to be conceiving of software design (and be a “technical person”), you simply have to be comfortable with the actual act of coding. That is after all the activity that makes the design real and has it own set of nuances and intricacies.

This means that no distinction should exist between architecture and the act of coding. It is an activity that should be a shared concern of an autonomous team building a system collaboratively.

Of course it helps being able to articulate architecture and highlight impacts of technical decision making especially in ways that non-technical people can understand. But that is a skill that every technologist should strive to perfect, not just the select few that carry the title of an architect.

The strangest version of this functional role is when someone that does not come from a technical background starts making proclamations about architecture and gets labelled as one. The subtleties of technology frameworks and practicalities of actually building coherent software systems would be completely lost on such an individual. Yet modern corporate environments are rife with these types of individuals who “build” systems every day.

So what is architecture then if anything at all?

Personally I like Martin Fowler’s view that if there is such as thing as architecture, it is essentially about two things. One is about creating a shared understanding in your teams and the other is actually investigating and answering the things in the projects that will be hard to change in the future.

The rest you can leave to your very capable and trusted development team.

The delicate balancing act of estimates, commitments and targets

“The act of not basing commitments on tangible estimates might make stakeholders feel warm and fuzzy, but they are living a lie that will eventually catch up with them.”

Software Estimation balancing act

Most people have never learnt the balancing act of good software estimation and are pretty terrible at communicating it.

I recently did an article talking about the inherent complexity of doing software estimation. I delved into the phenomenon of discovered complexity and how it is at the heart of why it is so hard to do reliable estimation in software projects.

Beyond the inherent complexity of doing estimation lies another problem. One of bad communication. Most people have never learnt what good software estimation looks like or what the right way of communicating it is. Business people involved in software projects typically view estimation as the domain of the geeks and as such make no attempt at understanding the nuances. Geeks themselves have spent most of their lives giving gut-feel estimates never learning the importance of communicating estimates in the right way.

Universally estimates get treated as commitments and commitments get communicated as targets. Most don’t even know that there is a difference between these concepts.

The general disregard for the purpose and value of software estimation has led to untold amounts of project failures that in turn has caused unprecedented amounts of frustration and trust erosion in many business domains. And as already alluded to it all boils down to the fact that people simply don’t understand the difference between estimates, commitments and targets.

Each of these concepts have their own unique purpose, so allow me to disseminate it for you:

Estimate

An estimate is just that, it is best guess at how long something will take given the information that is known at this point. As I explained in my previous article, it is inherently flawed and will change over time as unknowns become known and problems find solutions that can be estimated on more reliably.

As such a good estimate should be plotted against a probability curve that tries to quantify the uncertainty and risk that surrounds the estimate. Put in simpler terms you should never communicate a single point estimate (‘I think this will take 6 months’) but rather a range (‘given what we know this could take anything from 6-9 months’).

“Thinking of estimates as a range of possibilities (between the best and worst case) reduces the stress of having to be perfectly right.”

Thinking of estimates as a range of possibilities (between the best and worst case) reduces the stress of having to be perfectly right and caters for the inherent ambiguity and uncertainty involved in the software development process.

Commitment

This is the promise to deliver functionality at a certain level of quality by a certain date. The really critical thing here is to realize that estimates inform commitments. But a commitment cannot and should never drive the estimate. The working position should be that the estimate is flawed and commitments have to be based on the most pessimistic estimate maybe even building in more fat. If the estimate is not palatable then business stakeholders should actually do the job they are tasked with and make the hard choices of prioritizing what is truly needed in order to give the project a quantified chance of success.

Too often in corporate environments existing commitments are made even before a project is understood or a project team has even been formed. Unfortunately this is done purely to look good and to make people feel better about their reality. Frequently this is done to mask incompetence and hide how poorly a portfolio is being managed. Regardless, the act of not basing commitments on tangible estimates might make stakeholders feel warm and fuzzy, but they are living a lie that will eventually catch up with them. Sadly most of the time stakeholders will consequently blame delivery teams for failures, never their bad decisions.

“If you are trying to make a commitment that is palatable instead of based in what is the best version of reality (aka the estimate) you might as well sit in a boardroom talk about all your dreams and wishes (regardless of how realistic they are), high five each other and hit the bar to celebrate since that is all you are essentially doing.”

In summary, if you are trying to make a commitment that is palatable instead of based in what is the best version of reality (aka the estimate) you might as well sit in a boardroom talk about all your dreams and wishes (regardless of how realistic they are), high five each other and hit the bar to celebrate since that is all you are essentially doing.

Target

A target is a single-point hard deadline, usually driven by some business need. It is has absolutely no relationship to the estimate of how long a project will take. In a perfect world estimation would happen before planning. The team will then come up with commitments on realistic sets of features and the business will then set strategic business targets based on reality never on fiction.

Similar to commitments it happens too much that targets are already fixed before estimation is even done. Or estimates are done by people that are not actually involved with building the software.

The key thing here is that if the estimation is subsequently done properly, stakeholders have to have the maturity to accept that what is being asked might simply not be possible. However many act like spoiled children that refuse to accept that what they are demanding is not possible. Instead they choose to play the guilt card on the delivery team for not being willing to go above and beyond. They remain oblivious to the fact that they still get to go home every night to see their children and live their lives whilst their teams bleed.

“They remain oblivious to the fact that they still get to go home every night to see their children and live their lives whilst their teams bleed.”

Forcing engineering teams to commit to a date that is more palatable to the business might make stakeholders feel better about situations, but if it is not based in reality (most of the time) it will result in dramatic failures at a later stage. This is not what it means to be a responsible corporate leader and you certainly are not operating with the best interest of the organization at heart. Put simply causing chaos in the lives of your employees to make yourself feel better about things does not make you a good leader.

Tips for being better

Understand the difference between these three concepts and live them in your day-to-day life.
I understand that it is hard to face senior stakeholders and tell them that what they want is not possible, but as a leader that is your job. If you are not willing to act in the best interest of the team and organization by being truthful about situations it means that you are just pulling the wool over everyone’s eyes to cover your own faults.

Don’t give estimates on the spot.
A rudimentary functional breakdown and sizing exercise is already much more accurate than a thumb-suck gut feel. As soon as you communicate any date people will treat it as a commitment. So best be sure that it is based in reality.

Never ever give a single point estimate.
As explained an estimate should always indicate a likely range and should be treated as information and nothing more. It provides context for discussions about commitments and business targets.

An estimate range is allowed to be wide.
For some reason there is an obsession to make estimates as narrow as possible since people are actually really looking for a commitment. The range indicates uncertainty and the fact that it is wide is relevant information. It illustrates the amount of uncertainty that is present in the project and should form part of the discussion.

Estimates should constantly be revisited and updated.
As you progress in your project and figure out some of the uncertainty you should be adjusting and refining your estimates.

Us the most pessimistic estimate to inform business targets and commitments.
You are not doing anyone any favors by committing to unrealistic timelines because it makes you look better. It will fail and result in people blaming each other leading to resentment and a breakdown in trust.

Always ask whether people are looking for an estimate, commitment or target.
If expectations in conversations are clear so much of this dysfunction could be avoided.