Design a site like this with
Get started

Themes for CI/CD Release Pipeline

Themes for CI/CD Pipeline

  1. Continuous Integration(CI) – Build, Test, Package code
  2. Continuous Delivery(CDL) – Take the code to Staging (potentially deliverable)
  3. Continuous Deployment(CD) – Deploy to Production. Make it Live
  4. Continuous Monitoring(CM) – Monitor, Measure, Feedback and Notification on the CI/CD workflow
  5. Continuous Security(CS) – DevSecOps vision – Automate security on release pipeline.
  6. Continuous Testing(CT) –  Risk-based, Broad, seamlessly integrated into the software delivery pipeline 


<!–[if gte vml 1]>



It’s fine to be emotional about code

Good programmers get a bit emotional, sometimes aggressive, forcibly compelling and coercively convincing when they see poor quality code in the repository. At times, they land into protracted conflicts with the other team members about code quality issues and the priority at which they should get fixed. I have been in several of these unwieldy situations and heard distinctive reasons from programmers about “Why they checked-in that unwanted piece of code? “.  Some programmers stated that they have no time, they are under intense pressure to deliver and they just want to get things done.  Some
(The eager coders), constrained by their skills and knowledge, were more receptive and wanted to learn and change their code for betterment. I have also heard extreme statements and great proclamations like – “I care more about meeting deadlines for customers than writing good code. We can always re-factor it later” –  Management cherishes them and keeps these individuals forever (for their amazing adoration for customer deadlines). Actually, what they are trying to say is that they will write good code when in a project, requirements, budget, priorities, deadlines and teams will be fixed and under acute control to give them the luxury of good code development. They don’t live in a real world of ‘pragmatic software development’.

Let me bring some wise advice to these insane programmers, these minimalist minds who believe they have to write least quality code to get things done, and refactoring code is a ceremonial activity – an ostentatious action,  which is usually done if and when they have time (They will never have that time). Refactoring is not an exercise done on  deficiently composed, ineffectually  thought, wrongly intended working-code. It’s not a backlog item which needs to be prioritized later.  

It’s  hopeless to assume that one fine day
you will abruptly pick the crap you have created for months and fix it. Infect, an awful, terrible code never gets re-factored (Unless of-course, if your job or reputation is at stake). Refactoring improvements are about your experimentations with design; your intense desire to make ceaseless code and design improvement – everyday with every visit to code. It’s not an end-of-iteration or end-of-milestone movement. It’s an intense cognitive activity for improving the design of code that last difficult times after beginning the secret life into the repository.  How can refactoring be fortuitous activity accomplished after the working-code is shipped? No way! Good programmers write good code, even under extreme pressure of software factory, and they improve it continuously with slightest opportunity. They make real project constraints work for them and align with their exceptional yearning to forever produce excellent quality code. 

I have worked with some very good developers and also knocked my brain out with some lamentable ones – who ought never to be coding.
I have been in situations of authority and demanded code quality;  I have likewise been in consulting and influencing positions, where its hard to get what you need in code. I still need to learn the “Art of getting things done when you are not in-charge“. I have tried defining and establishing coding standards, put peer pressure to code well, shown it by example, tried peer programing, passed on books, articles, blog links, practiced group Test-driven-development,  tried  collaboration and knowledge building tools and so forth. All these things have worked for me in projects. Now and again they haven’t.  

I recall re-writing entire production code developed for past one year in straight 4 months with a new team. We called it code refactoring that time, so that code owners don’t get offended (or embarrassed). My company never ascertained the cost of re-writing. Infect, I was asked about the ROI of  refactoring the work well-done. I never knew how to convince  project management that the code they released with enormous fanfare was almost impossible to extend, maintain fix, and was the cause of the large bug list and customer dissatisfaction. I could not get the project-time for the team to work on these mammoth re-writing effort. We did it off-line, in-parallel to day-to-day deliverable and re-wrote most of the existing product code. Six months later, we had some positive feedback about reduction in production failures and improvement in  customer and partner sentiments. Programmers who composed that earlier code-crap, got promoted for meeting all deadlines. I am still in touch with developers who re-composed the new improved code.

I wish, I had a tool to measure the cost of poor code quality to the company – every day, every hour. I would have displayed hourly metrics on the big screen for every bit of code that gets checked-in (I understand that’s too much of a love for “Beautiful code”).

I often wonder, why programmers undermine the product quality with deficiently composed so-called “working-code” (and still earn their credits)?  It’s so easy for programmers to trick uninvolved management  and project stakeholders in the short run. More often than not, management has one single measure to track the project progress and current risks to delivery – It’s their sheer capacity to  meet immediate milestones and demonstrate a working piece. Furthermore, they see programmers’ productivity in terms of total work delivered, total tasks completed and aggregated errands finished. Productivity seen in context without a reference to quality is not an effective measure. Bad Programmers are shrewd to use these limitations to their benefits(not in all companies though). They write code that sucks, make it work, make it breeze pass through a QA tests, release the product, add the work done to their resumes and then wait for a large backlog of bugs to be formed for creating strong dependencies on them during the long maintenance cycle of this “Big ball of mud”.  They run iterations after iterations of fire fighting and bug fixing to make it suck more (and they earn more credits for fixing it). Management is happy as they see everyone involved and loaded.  A quick analyses of bug backlog in these situations will reveal that number of these bugs should not have been there if programmers would have been less rushed and hasty, and more careful, thoughtful and attentive about the code. If the programmers had cared to learn some new stuff, Googled a bit more, reviewed their code with someone, re-factored it, composed some tests to verify their code or simply visited their working-code once more they would have been able to avoid many of these large bug backlog pains.  These rushed and eager code monkeys say- “It works, it meets expectations, it has passed the QA tests, and shipped product will always have some unknown bugs which cannot be avoided”. They forget that complex-poor-code will discover new, unimaginative ways to generate new types of bugs. Technical debt will shoot like a chain reaction and grow like an irrepressible cancer killing your ability to enhance product. It will consume your capacity and budget; it will slow you down; and it will frustrate your people. Project Management teams find it hard to handle these situations. The only way they think they can ensure product quality  in these circumstances is by having a QA team of much greater size compared to the programmers team, and working for longer release cycles (Quarters and years). What a way to ensure employment to people.

It’s not easy to convince programmers and short-sighted project management that:

Working code”  !=  “Shippable code”  &;
Working code”  !=  “Work Done” &;

Working code”  !=  “Correct code” &;

Working code” is also  !=  “Well Crafted code”.

Infect, this whole understanding of  “working-code” is flawed. It’s so easy to write code that works most-of-the-time and call it a “working-code”. This “Make it work for now” attitude has cost a lot of companies in the business of writing code. It indicates very constrained and obliged mindset of people who develop and lead these projects. Is the only purpose of writing code is to ensure working features quickly? What happened to your system quality concerns – Maintenance , performance, scalability, modifiability, extendibility, adaptability etc.. Big-cost of the project comes when we address these non-functional requirements. I have hardly heard a technical stakeholder  pose a question like – What is the quality matrix for your classes and functions used to develop this feature in the current iteration? What is the improvement in technical debt? Which code did you improve in this iteration? They silently sit thorough end-of -iteration demo’s watching working features. I am a great fan of end-of-iteration product demos. It’s the only way to verify that you have built “what product stakeholders truly wants not what they said they need”. But, unplanned , unorganized, unconstrained demos to show stakeholders the project progress has a profound negative impact on the design and code quality. Programmers, pressurized to deliver the working-code for the demo, deliver “The working code”, but  that is never the “Complete code”. Teams need to define their “Definition of Done” with intense code quality criteria  and ensure that all user stories they have developed in the iteration do meet this “Definition of Done” for the code before they demonstrate user stories to the stakeholders. 

What differentiates passionate programmers, those who build incredible products from the common ones who write very ordinary code (to make their living), are intrinsic qualities and virtues of CARE , ATTITUDE, SELF-DISCIPLINE, HUMILITY, EMPATHY, backed by excellent programming skills, great technical competence and continuous desire to improve 
(as if, in a long, never-ending, journey of mastering the ‘craft of great coding’).   

Care brings sensitivity in your behavior and action, it ensures serious attention, genuine consideration and application to do things correctly and avoid any damage or risks to others. If you care about the product, customers, peer programmers, QA, support and maintenance people or any other who is affected by your code, you will ensure you always craft good code. 

Positive, rational attitude opens your mental locks, provides you with a lens to evaluate everything correctly and judiciously. It inculcates professional approach, helps you rise above wishful intentions during extreme times by building mental models which foster positive perspective and intense desire and commitment to code quality and software as a whole. It brings that motivation to continuously learn and improve whatever you do. And, it applies to the code you compose every day at work. 
Self-discipline with a consistent commitment to self-development is the number-one approach for building competencies in an individual. Self-discipline refers to the training that one gives one’s self to accomplish a certain task or to adopt a particular pattern of behavior required to achieve desired goals (A great code). Self-discipline helps you build perseverance, restraint, endurance, thinking before acting, finishing what you start doing, and the ability to carry out one’s decisions and plans, in spite of inconvenience, hardships or obstacles. It helps you build great programming skills and consistently practice and improve it to perfection.

Humility is an essential characteristic that helps programmers to be accepted and respected in the team. It helps in building collaboration and relationship of mutual trust in the team. Humble programmers want to make genuine contribution to serve the team. They share knowledge and contribute to the growth and development of others. They help in creating a learning environment and culture of shared knowledge and continuous improvement. Good code gets written when everyone in the team is committed to excellence. 
Empathy for peers – people who will use your code, programmers who will integrate and maintain your code, programmers who will read and learn from your code enables you  to have an emotional connect with other programmers in the team. With empathy for other stakeholders of code it is not possible for programmers to hand over a sub-optimal code to his colleagues, sub-ordinates and inflict pain and sufferings.

These  qualities of programmer build the right mental models necessary for development of incredible programs. 
Good programming knowledge exercised within the discipline of these qualities create competencies which are necessary for writing great code. Simply having right programming skills do not get good code automatically. Without an extraordinary desire to do the right things, and with long-term vision it will result in skills applied to achieve short-term sub-optimal goals. No unfettered enthusiasm can produce quality code. It has to be supported by skilled craftsmanship with passionate adherence to these qualities. These qualities also help you in honest appraisal of your own skills and knowledge; which is very important for developing a learning attitude necessary to be a journeyman pursuing a never ending journey for mastery of the art – The art of writing the great code (Check out this article from Kruger and Dunning – Unskilled and unaware of it…). These qualities shape the assumptions you make (Or avoid making them) while conceptualizing, reasoning and drafting the code. They help you build code that last  and sustain the emergence and extensions requirements  of future with grace. It’s difficult to see and understand how your qualities like ‘attitude’ will shape the quality of the code you produce. As you think and practice more of these qualities, they become ingrained in your mind and reflect as ‘habits’. Good habits have a positive and effective re-reinforcement – the more you practice, the more fundamental behavioral changes they bring.

It takes a lot of time, commitment and effort to develop these intrinsic qualities to write good code, they are sometimes ingrained in the culture and values of the organization, experience of developers and their background – their values and principles, colleges they attended, people they have worked with, how they have grown in their professional career, how they have learned and acquired skills and knowledge and how they have been measured and mentored. All good learning minds poss these qualities and consistently exhibit them, not only in their coding activities, but in everything they do and value. 


Project management barely measures these qualities (Call them competencies). They do not know how to quantify them. Even if they do, project management is so short-sighted that they cannot see things beyond immediate releases (At the same time, they do like to have year long plans and want to get everything in their control). I don’t think you can have one disposition towards code and different towards your other delivery activities.

Passion for writing a great code also has it’s impact on the teams and the organization. Programmers who will care about good quality of code will care about  their team, their colleagues, the quality of deliverables, quality of customer satisfaction and business success. They will set high standards on everything they do and improve, they have more chances of innovating and creating new things. Passion for quality is a state of mind achieved by continuous commitment to excellence. 

Your code evolves, shines, emerges through precise improvements, refactoring  experimentation, insightful discoveries and thoughtful reviews. Revisit, what you wrote last day,reflect on it, improve it, consult and review it with peers; Never close it forever. 

Coding is a craft which gives you an identity and defines your attitude. It is what you are and speaks a ton about your passion towards what you do and what you relate to. Code conveys lots of things about the team work and quality of work you produce – it communicates your attitude towards what you do,  quality of teamwork, relationship and collaboration between team members, quality of development management, what gets measured in the team, motivation and frustration levels of the team members(who are going to leave soon. ) etc.. I have seen two people sitting side by side writing very different quality of the code. Even when they were actually working on the related modules, they never cared to collaborate, to look into each others work and learn. On the other side, there are programmers who have learned from open source communities by looking into the  good code developed by remote developers they have never seen.
If you believe that you are a craftsman on a journey to achieve mastery in ‘the art of coding’, you are bound to get emotional when you encounter incidents where code quality is compromised. It’s natural and expected behavior. So, next time you find yourself in some conflicting situations with developers  while discussing the code quality and get a bit aggressive, demanding, compelling and later lament your act, I would say, let it go, be cool.. It’s fine to be emotional about code“.

Yeah… but don’t thrash people and don’t be condescending, and demeaning of others efforts. Encourage them, honor their opinions, appreciate what people do, teach them good coding techniques, help them to build the qualities.

Which of this books have you read and practiced?


Crafted for excellence – Journey of a software craftsman

Are you a developer hiding your code or hiding behind code?
As a developer, are you passionate about what you write?
Do you believe that coding is a craft which gives you an identity and defines your attitude?
Do you write code that works now, or code that is build to last?
Do you understand the complexity of  the art-of-coding and path to simplicity?

Are you an excellent craftsman at work?


Frequent management interruptions for developers – A big lean waste in software development

Why do developers disdain to go to regular meetings? Besides, Why managers consistently call for such a variety of meetings everyday?

As a developer, we understand, how tormenting it is to pick your notebooks and go to the conference room for an extensive management meeting amid an occupied busy day.  Particularly when you are profoundly involved in brain-teaser design and development work and desperately need solitary confinement to squeeze your brain cells to get the technical problem solved.

As a manager, we always believe that developing communication structure within and between teams for tenacious, persistent, continuous communication is of significant importance for developing an incredible product. If you are an ‘Agilist‘, you are committed to required daily stand-up meetings, iteration planning meetings, iteration review meetings,  user story pruning meetings, iteration and milestone retrospection meetings. These meetings are important to close the feedback loop between teams, within teams and for an individual developer at different phases of product development. These feedback loops enable and empower continuous improvements in an iterative and incremental development environment. Agile needs regular feedback loops to drive the time-boxed iterations, get the team in a shared mindset and align product development activities with the product plans and milestones.

In a 2 week iteration, if a developer dedicate 15 minute per day on a daily stand-up meeting, 4 hrs for iteration planning meeting, 4 hrs for iteration review and retrospection, 2 hrs for product backlog pruning, It is 15.6 % of the total time(80 hrs) an individual developer has in a 2 week iteration. Investing 15% of you time in an iteration on effective meetings which enable development activities is not that awful for developers. The problem comes, when developers are frequently interrupted in their core hours, during the time when they are deeply engaged in design and development activity. This interruption can be in  the form of unplanned meetings, interviews, cross-cubical talks, manager’s room chit-chat,  unnecessary on demand sink-ups, management updates, group task reviews, and so on..

Development,  particularly coding is a complex activity. It requires collective, cognitive alignment of numerous elements – mental models of problem definition and the environment, understanding of  requirements and acceptance criteria, conceptualized solution options, approaches, design decisions, risks, assumptions, constraints, experiences, influence, understanding of the evolution and emergence of code and design etc. It is a challenge to bring all these elements in-resonance to discover and code the ideal solution. Interruptions, derails the cognitive processing. Interferences, crashes the cognitive transformation of ideas to working code. It makes developer mind to do a context -switch from one problem to another. Problems which are different. Problems which requires different cadence and mindset. When developer returns to development activity, it require them to re-build the mental structure and state. It can be like starting again.

Now, if you are repetitively doing the same kind development activity for a long time and your mind is hard-wired to repeat, you wont’ psyche getting intruded on, and  your manager will love you for being so effectively accessible to him for on-demand dialogs. But, development brings new insight and learning every time you code. Each coding circumstance is different. You have to be alert, investigating, exploring to get the right code artifacts. Yes, even when you are using Google to cut and paste, your mind need to be active to learn and adapt it to your problem needs.

I ponder, why managers require these frequent sink-up meetings with team members. Particularly, if you are doing agile and committed to iteration deliverables. Why do they need to chit-chat regularly with the developers and discuss what you are doing now. Can’t managers join the daily stand-ups and get the status? Don’t manager trust the team’s sprint commitments, skills, knowledge, ability and capacity to deliver on planned work. Particularly, when they are themselves involved in building the team. Shouldn’t the manager spent more time facilitating the iteration review, iteration planning, retrospection meetings, and work on cross-teams communications, competency and skills development, individual’s objective alignment achieve bigger and broader goals?

The bigger question is – What do managers do in agile development?
This is not the topic of this article. I will answer it in another post.

Management and development work require different cadence to achieve its goal. When you are on developer cadence – designing and coding; the daily cadence cycle is longer. I see, 2-5 average non-stop hours required to achieve development tasks. Interruptions during these development core hours break the rhythm of a developer. This context switching can make developers loose the thread and  blow away the entire day for them.

Developer’s and Manager’s work cadence

When your in Test-Driven-Development mode, a management call to discuss status updates can get us out of the context instantly. Here, we just composed a test to express what we intend to code, Interrupted!  we lose the rhythm, the context and the mental-model of it. It takes time to re-build context, to go through the code again, and understand what we were thinking when we actually coded those tests. Everything requires significant re-investment of time and effort- A rework, a big waste. Not to mention the frustration it brings with it.

If you are working on management tasks, cadence cycle is shorter. Managers can switch between tasks within minutes, multi-tasking is accepted and recognized way of doing day to day management work. Management tasks – email updates, co-ordination meetings, status updates, risk assessment and mitigation planning, work facilitation, task planning, resource and capacity assessment etc. all can be composed in of shorter time activities.

Managers need involvement  and participation of development team members to accomplish their work. Since, in most of the projects, managers are in more authoritative and legitimate positions, their call for unplanned short gatherings tend to drastically affect the developer’s development activity.
Manager’s  tend to disrupt  and upset the development activities several times a day. They are unknown of the fact that this regular interruption is causing a context-switch for developers which takes time to reconcile and is prone to loss of information, ideas, approach, problem modeling and solutions. It will reduce the quality of output, lower the productivity, increase re-work, affect the developer’s motivation and commitment and leave them exhausted.

Have you observed the complex behavior of a swarm of ants who have discovered a food source? Disrupt it! What amount of time it takes for the ants to return to the same behavior?

What can be done to bring these two required but distinct behaviors(Managers and Developers) in collective-cadence to achieve the desired shared behavior?

Give some attention to these important points:

  1. Managers should understand and recognize that there are two distinctive types of task schedules in the software development teams  – management tasks and development tasks schedules(which require involved coding and testing).
  2.  Everyone should understand the effect and waste caused by context-switching of development activities.
  3. Managers should learn to avoid frequent interruptions and allocate time for co-ordinated tasks which require involvement of development team members. Like, fixing the meeting timings in the afternoons or sending the meeting request, instead of an on-demand interruption.
  4. Managers should avoid the habit of frequently dropping by the developer’s desk or making calls for on-demand meet-up. Instead, keep a list of required communication and interruption logs and allocate time to do it when the developers are relatively free. Have empathy for developers schedule.
  5. The impact and intensity of waste due to context switching will depend on the type of development(especially coding) work. The more involved and collaborative a development task is, the more will be the waste in context switching.
  6. Developers need to understand the importance of accomplishing the management tasks for the project, and dispense time for it as a team in coordination with managers.
  7.  If the developer feels that interruption and context switching is going to create waste, he should inform the managers and appeal for alternative time to meet. Yes, I understand, many managers will get offended if you request for a change in meeting schedule. They always want it now!  I ask to these managers, isn’t ensuring high productivity, quality and facilitation of uninterrupted development activities your primary goal on the job?
  8. Are you an involved manager? Do you understand and have feel for complex coding exercises? Or Do you think, coding is like any other monotonous task which developer can perform without much attention? Because if you do, then believe me, you are soon going to get the team down. Good developers will leave you to work with better managers.
  9. Listen to your developers, and develop a working schedule for shared activities.
  10. Developer needs to structure their day. Know your schedule, what development tasks you need to accomplish, there complexity and communicate the same to managers.
  11. If developers can’t avoid some interruptions, it is recommended to record their last thoughts before joining the meetings. It will help in resuming the task again.
  12.  Developers can move to meeting rooms when they are working on complex, involved activities which require uninterrupted focus.

Are you a hands-on architect?

What do you do as a designated Architect of the team? Are you still hands-on with implementation design and coding?

Hands-on Software Architect

Do you spend most of your time creating an up-front architecture and design with lots of artifacts(Architecture views, process and flow diagrams, models etc) and posting these architecture and design documents for reviews, updates,  presentation to the management and development teams for feedback and comments? Or Do you like moving quickly to evaluation, validation and experimentation of your design and architecture by quickly implementing the skeleton architecture with the development teams and other stakeholders and following it with validated architecture refactoring and iterative evolution?Do you consider working skeleton-code with running tests as an architecture artifact? These are a few questions which define your architecting mindset and process followed to architect and design.

Software architects find immense satisfaction and pride in developing the architectural artifacts in  isolation with the occasional ceremonial presentation. They find more comfort and security in their isolated ivory towers. Inspired by the real-world infrastructure architecture and architecting process, software architecture has been envisaged as a big up-front process, only for specialist –  ‘An art’, which can be performed by fewer designated individuals. They communicate occasionally with artifacts created in isolation, and leave as soon as possible to enlighten other projects.

Lonely Architect

I see following reasons for this “Architecting-in-Isolation” mindset in architects:

  1. Software architects do not understand the boundaries of software architecture. They tend to do a lot of up-front design with limited feel for  a ‘Just enough architecture’ which can enable quick design and implementation.                                                                                                        
    Undefined boundaries of Software Architecture 
  2. Software architects do not emphasise on continuous validation, evaluation and experimentation of architecture. Architecture does have elements which can be re-factored,  iterated, and developed incrementally with more validated learning and feedback from stakeholders.
  3. Software architecture and design emerge and there are many unknown-unknowns. Architects tend to assume lots of things up-front. They cover it up with known architectural styles, patterns, past experiences and best-practices and ignore the fact that architecture and design will evolve and emerge as it get coded.                                                            
    Unknowns of Software Architecture
  4. The architecting cycle is very long, non iterative and incremental, and executed away from the development process. Architecting process is detached from the development process.


Software Architecture and Development teams in isolation

There are other reasons which keep architects away from the development teams. Like, involvement in other  parallel projects. I will not discuss them here.
One big challenge architects always face is in deciding when to stop up-front architecture and design work, and start enabling design and implementation. Most of the time, architect tend to overload lots of detail in their early architecture artifacts. They attempt to define, every component, every interface, many views and system quality concerns; almost every minute detail that crop-up in their minds at the early phase of the product design. They tend to make lots of assumptions about the design and architecture without validation and verifications. Working away, in-isolation, from other stakeholders, they do not know what is just-enough optimal architecture and design  for development teams to get going with implementation. They do not see the waste they are creating by big up-front design activities and impediments bought to the flow of agile and lean development of working and well-crafted software.

Architects needs to embrace lean and agile architecture and architecting process. They need to get their architecture artifacts consumed as soon as possible in the design and implementation iterations. They need to understand, that working code, which can validate their architecture decisions quickly and help them to evaluate design options is more effective than big architecture document created over weeks of isolated research. Now, I am not saying architecture should not be documented.  Documentation can always be done incrementally and iteratively. Just lay down enough details, avoid long component diagrams, class details, pages,of flow and sequence diagrams, data models and deployment scenarios etc. Keep it simple, short, quickly communicable and consumable.

Even if it takes to write only just few draft pages, few wire-frames, hand sketches and board diagrams, Do it!. It has to be lean. Avoid all forms of waste which do not add value up-front.  Design, in short iterations, communicate continuously,  work closely with your developers and code for the skeleton architecture and cover it with the unit and acceptance tests. Take it to other stakeholders – product owners, Dev-ops, QA etc for reviews and feedback. Continuously re-factor and iterate over architecture and design. “Validated learning” about the architecture obtained through incremental architecture development and continuous validation is more effective than big up-front architecture and design activity which do not add much value and is very difficult to validate.

Now, experts will debate on how much you can actually re-factor software architecture. Well off-course, not to the extent that you can re-factor code, but yes, there are elements of architecture which needs to be  iterated and re-factored. Like, components and service interfaces  can be understood only after understanding the component usage and interaction patterns, service and resource relationships and dependencies. Interface design needs continuous refactoring. If you try to identify and design all your interfaces up-front, by making all architecture decisions at the start, just imagine the mess.

Functional models, Data models, thread models, development models, process and deployment models all evolve as you learn more about the system and its architecture and design. Sooner you get the working software, better you can evaluate and validate your architecture and design.
Which means architects need to be hands -on. They should be working closely with the development team to ensure that architecture and design is quickly and correctly translated into working code. 

Try this to successfully achieve incremental and iterative architecture. Based on the known use-cases and user stories,  list down some known high-level components, their relationships, important interfaces, some notes on desired  threading models, sketches of data models, few non-functional concerns and constraints like failure scenarios, required performance with measurable numbers etc. Enable some early-communication and brainstorming discussions with the development team.
Even before you document details, sit down with the team to code the skeleton architecture components and elements with the acceptance tests for the required user stories.  Define and name the system components and their interacting behaviour and interfaces. Define both the construction and interaction behaviour of the components. Functions are implemented with with no real code but well named classes and behaviours and covered with tests. Use ubiquitous domain language to define the components, classes and function names. Run the tests to ensure that component wiring is complete and correct with right interfaces as per the use cases. Ensure tests are developed and become the specifications of the desired behaviour.

The important thing for an architect is to know how much time she allocates for herself  to get involved in day-to day implementation and design activities as early as possible and  see the architecture getting codified.  This is the only way to know how well the architecture is realized in design and code.
I believe, coding is a  designing-activity and lots of design actually happens when we code. Can you see your architecture and design in code?

Try to answer the following questions for yourself:

  • How much detail is enough to create and communicate architecture?
  • Where do we think that the architecture is just enough for design and implementation  to take over?
  • Do you know about the risks associated with each element of architecture? Based on these risks how early you get these things designed and implemented? How much time you allocate to risky architecture component’s implementation?
  •  Do you continuously validate your architecture? And how?
  •  How much are you involved with the development team and how often do you receive the feedback on the architecture and design issues?
  • Do you see architecture and design getting evolved as you code and implement? And how?
  • What is your architecture documentation process? is it on-time up-front process?
  • Are you still coding? Do you allocate time to get involved in implementation and coding? Coding exercise will help you to understand the architecture and design decisions better.

Creating Lean and Agile Software Architecture

“The lean and agile way of developing software architecture” has been my primary area of study for some time. I have been doing research study on this area and developed significant understanding of what researchers and practitioners of agile software development and software architecture have to say about this challenging subject which has been mostly ignored by lean and agile gurus and coaches in their expression of agile methods and principles.
 Many extreme agile practitioners and thought leaders discard any form of architecting activities in agile environment. They believe that software architecture emerges as result of incremental and iterative designing and implementation activities of teams and can be re-factored to the desired structure incrementally throughout the implementation cycle. This group of agile practitioners views all upfront architecture and designing activities as waste, documentation-intensive and high ceremonial activities which slow down the early valuable delivery to customer and reduce capabilities to respond to changes. They embrace principles of ‘YAGNI thinking’ (You aren’t gonna need it) to extremes, and controvert any upfront architecture-centric work during software development.  
On the other extreme are those ‘software architecture perfectionist’ and agile phobic groups who believe that software architecture in large and complex systems requires extensive, careful planning, upfront decision making, deep analysis, synthesis, centralized evaluation and it cannot be left to iteration teams to make those critical architecture decisions during their daily design and implementation activities. They are skeptical about the effectiveness and reliability of agile methods to solve software architecture problems. They are uncertain and fearful about the changes agile practices are bringing to their traditional and centralized software architectural practices of ‘big upfront design’. How often have we heard this in skeptical scrum team?  –  “Agile says no to architecture and design, so we did not do any at the start of the iteration. There would have been less re-work and no re-factoring issues if we had designed it all upfront”
As lean and agile approaches mature in handling software architecture in complex products, there is strong realization and need for complementary approaches to blend software architecture and iterative lean and agile software development activities by principles and practices for better quality software products and processes. Especially, large and complex software system development teams have realized that efficiencies, flexibilities and reliabilities of agile methods have to work in synch with effectiveness and elaborate details of established software architecting practices, which reduce cost and time, and provide an integrated and structural approach to software design and development. There is a need to architect solutions which embrace change, and design them within an incremental, iterative and shared framework to incorporate continuous feedback from all stakeholders. This means, software architecture has to be agile by its ‘form’ (structure) and by ‘process of architecting’. A shared, and consistent understanding of software architecture need to exist in different agile teams to realize agile architectures. Lean and agile methods can no longer ignore the software architecture aspects and there is immense need of a unified , collaborative and coexisting approach to architecting and designing lean and agile software. 
I plan to present my thoughts in a series of following upcoming blog posts:
  • Integrating software architecture with Lean and agile software development principles and practices.
  • Lean and agile software architecture by form and structure.
  • Lean and agile software architecting process
  • Differences between traditional and lean&agile software architecting.
  • Who are agile architects and what do they do differently
  • How lean and agile principles guide software architecture?
  • Tools, techniques and artifacts for agile and lean software architecture.