Wednesday, December 20, 2017

Achieving success



When considering performance, there is typically more focus on failure than there is on success. Failures are often noticeable, well-remembered one-time events that generate high emotions and can affect many people.  There is the idea that teams learn from our mistakes and failures, and that in order to improve teams must fail publicly and painfully. It is believed that significant successes must somehow be rooted in overcoming past misfortunes and failures.

Success can be loud and come with a lot of fanfare as well, but the fanfare of success tends to fade faster.  New challenges pop up and emotions go away quickly because the team must get back to work, as success tends to bring in more work and generate additional challenges.  

As a result, success appears to play a smaller role in overall evaluation than failure.  That is both unfortunate and counter-productive.  

It is unfortunate, because failures are not necessarily what makes us learn and improve going forward. While occasionally there is learning that is an outcome of failure, the same learning can also happen without experiencing the fail.  A lot of failures are unavoidable, but nevertheless result in blame (or self-blame) and reduce motivation.

Focus on failures is also counter-productive, because failure is hardly ever the enemy. Failures come from experiments, from aspiring to reach farther, from ambition.  Statistically, it takes a number of failures to achieve significant success.  Without these failures, the success is either impossible, or a lot less likely.

Success is not the opposite of failure, rather, it is a significantly different happening.  Success often comes with more work and more responsibility, creates additional challenges, and pushes the team to work harder.  Success requires active learning and deliberate practice, and there is a need to learn still more to handle challenges brought on by the achievement.  Success encourages ambition and experimenting, and boosts motivation.

Success is the main driver of future success. It is time to focus more on success, and less on failure, when considering team performance. 


Monday, September 25, 2017

Deciding the architecture


Agile project starts by gathering an Agile team, deciding on a project and specific deliverables to be built first, and setting up the needed infrastructure. 

But before the team goes about creating the infrastructure, several questions about the system architecture need to be addressed.  What infrastructure will be needed, and what skills the team must have, greatly depends on the proposed system architecture and technology stack.

Who decides system architecture is the “elephant in the room” issue of Agile projects.  Many smaller design decisions will happily “emerge” as the team goes through the daily work of building the project iteration after iteration. Still, there is a number of large-scale, long-lasting choices about system architecture, that must be decided at the start of the project, when relatively little is known and the team has the least amount of experience on the project.

Who should be making these decisions? The typical answer appears to be The Architect, someone high up in the ivory tower, someone who makes no mistakes by producing little to none tangible, and thus imperfect, results. Sometimes that person is very good, and in other cases they just get by.  As it turns out, making the very best initial architectural decisions for a given project is not particularly important for the project's success, and making passable architectural decisions is fairly easy and fool-proof. 


List of common architectural patterns is very small, and almost all projects fit nicely into that tiny set.  Even if an inappropriate pattern is picked, the team will be fighting, and winning, over the inappropriate pattern to create a working implementation.  If the system becomes successful despite poorly designed architecture, and fighting the system setup becomes a serious obstacle to evolving the product, it will get re-written with a less inappropriate architecture shortly.

P.S. 
Sydney Opera House is one of the most beautiful and distinctive buildings in the world. Its architecture went through a dozen iterations of design, and the finished structure exhibits terrible acoustics - a big problem for an opera house and performance venue.  The building took 10 years longer than planned, and went 1,357% over budget. Of course, the project was, and still is, a resounding success.




Sunday, July 30, 2017

Scrum as a series of feedback cycles


  • Daily scrum: every 24 hours, within the Scrum team. Feedback on technical details.
  • Sprint review: every 1 to 3 weeks, within the product team. Feedback on requirements, features delivered, and implementation details.
  • Retro: every 1 to 3 weeks, or, better yet, on as-needed basis, within the Scrum team. Feedback on communication, processes, resources.
  • Backlog grooming: every 1-2 days or even more often, within the product team. Feedback on features delivered, technical details communicated, and user feedback.
  • Sprint planning: not a feedback cycle on anything… why is it a part of Scrum?