Tagged: Process improvement
Working Horizontally (agile) & understanding Horizontal Management (work/team structures) and its issues
In line with the content on SDLC and ALM, along with today’s needs and desires for teams to be more flat.. or vertically structured: My next few posts are going to be about working horizontally, or horizontal management (work/teams/structures), or. let me throw in a buzz word .. “working in a more agile manner” 🙂
Horizontal management is: about working collaboratively across organization boundaries. There are no hard and fast rules to horizontal management it is an art more than a science. This type of management is pervasive, occurring at entry level in an organization. It involves bringing people from diverse organizational and occupational backgrounds together into teams and networks with a common purpose and shared culture. Group thinking is encouraged, but this can be seen as a risk because it cuts lines of accountability and authority and pursuing consensus at the expense of serving the public interest. [*]
In a nutshell, working as a team/group is working horizontally. One might think that working as a team is an easy task as we all have done so at some point in time, but this is not the case when teamwork is the bases that can make or break the success of an initiative, especially when used in complex processes like software engineering and process improvement and we are in a teamwork state for long periods of time. There are various dynamics that come into play when working as a team, for example some might not get along or trust other members, some might not be motivated or good team players and others might forget their individual responsibilities. Working as a team requires that everyone get an equal part so that everyone has an equal interest in working together, towards a common goal, build long term relationships and be equally motivated for the long run. An interesting relationship between horizontal structures and software development is that working in a horizontal structure is viewed as an art, which is the same way that software development was viewed as before it was realized that it needs to be a manageable process, our focus will also be to help make horizontal management a manageable process.
Some of the issues that horizontal structures bring with them that need to be addressed are:
- Working with others as a team slows down fast paced, ready for action members
- Members are sometimes not motivated enough to work as a team, which damages team effort and progress
- Members usually trust their own judgment and find it hard to put that trust in the hands of others
- Each member may have their own vision and own motive, maybe a goal they want to accomplish as part of their job function and have their own priorities.
- With everyone on the same level, who provides direction and leadership? Who is held responsible?
- People need to be assured that their time and effort is resulting in progress.
Key Dimensions of horizontal management
Working as a team rather than working as an individual does bring with it a few issues that need to be addressed:
- When we work alone it is easier for us to switch gears and start making progress because we don’t have to wait for others to be ready, progress begins when oneself is ready, in a team progress begins when “everyone is ready”.
- When we work alone we know what our goal/vision is, we know what we want and know how we are going to get there if we start straying away its really easy to pull ourselves back; When we work as a team, its possible that not everyone knows that the common goal is, they might have their own goals or own ideas of how things need to be and what takes priority over the other, when working as a team its important to make progress by combining all efforts towards a “shared goal/vision”.
- Working alone means that you are responsible and accountable, you need to get the work done and you need to manage your own time, when working as a team, who does what gets blurred this is why a “support structure” must be in place (depending on the requirements) so that vertical roles and responsibilities are not forgotten.
- When you work alone, since you are in control (and responsible) of the progress, it is easier to maintain your momentum, you know how much progress you have made, you know how successful you have been and if needed can make changes to help maintain momentum; Teamwork introduces attributes that may effect momentum such as meetings that go on forever, goals that seem unrealistic or far fetched, not knowing if all the effort in working as a team is paying off or not and so on. When working as a team, we must be able to “maintain momentum” on a daily bases.
Hence there are four key dimensions for horizontal management that revolve around horizontal structures and keep the horizontal structure/movement intact: [*]
- Mobilizing team and networks: Ready for action
- Developing shared framework: Working for the same goals
- Building support structures: To keep Horizontal team in check with Vertical roles
- Maintaining momentum: Keep progress moving
Each section would detail a significant amount of content so I will break it up into 4 posts to cover this topic….. eventually.
[*] = Hopkins, M. Coture, C. Moore, E. Canadian Centre for Management Development, 2001. Lessons learnt from Leading Horizontal Projects
Application Lifecycle
SDLC along with the words “Agile”, “Iterative”, “Kanban”, etc are, in my opinion buzz words. You can pick up a book and learn “Agile development”, you can take a few courses and get your “Scrum Certification”, but following the documented approach, as is, will only get you so far.
To really understand SDLC you have to get into the guts of how things really work; why do people do things the way they do and understand the “natural processes”.
For Start-ups, small companies, new companies, walking in one day, or starting of with something like “We are going to follow agile development”, works. It works real well because they choose to start with the textbook definition; it works real well because you have new developers who will be agile and flexible, and do things the way you choose to do. For such an environment, someone can walk in and make sure that things are being followed the way they are supposed to be; but unfortunately, this is not how it works when you try to take something that has been running for a (very) long time and you try to make it different.
As an example, look how some auto manufacturers have decided to implement and offer “high MPG vehicles”; some chose to restart and build a brand new vehicle; others attempted to re-purpose or salvage their offerings.
So talking about SDLC methodologies; Who really wants to follow a waterfall model? that makes you sound too outdated and boy, I wouldn’t want that on my resume. (Sarcasm). For many, waterfall is still the best methodology but they still want to move to something that’s more agile; and there is no harm in doing so, just as long as you understand and implement something that works well for you.
Now, to build something that works well for you, you really must understand YOUR current “Application Lifecycle” and see how it can be optimized. SDLC is just a very small part of the “Application Lifecycle” and once you understand, document and optimize your “Application Lifecycle” you can focus on modernizing your SDLC.
So, to build the example of understanding the “Application Lifecycle”, I will draw up a few diagrams. I will focus on the positive paths and not the negatives so that the model doesn’t get too complicated and I will also make some assumptions/skip extensive detailing, saving that for a separate post.
Starting the cycle.
- Once you have gone through all the (painful) steps of creating a product (in no order: Sales, Requirements, Dev, Qa, Test, Release, Etc) you end up with Product
- Customers use this product and they
- Report issues
- Reported issues go to your support team (hopefully)
- and the support team analyzes these issues.
Pretty simple right?
You have now documented the beginning of the cycle as after product deliver, you are getting things back that require work. So what does support do after they Analyze the issue?
- Confirm the issue and provide additional documentation (if needed), sending it to
- Some review board, or decision maker as to what to do with this supposed issue, and determine if its something that needs to be resolved now (defect) or something that needs to be done at a later time (enhancement), or maybe you do not want to do it. In any case,
- The review board makes a decision in regards to releasing it (now).
At this point, hopefully there is some queue setup that allows intake of things for development to work on as they will trickle things into their work queues (depends on what SDLC methodology you follow)
- Development picks up work and resolves the issue; after the issue is resolved, it is
- sent to QA for additional testing, and once
- QA approves the resolution, its
- given to Release Management, who then
- releases the resolution
- giving you a packaged resolution.
All this assumes that there was actually a code defect, and that it required immediate resolution as it was critically impact a live customer. Things get a bit more complicated when you bring enhancements, non-code issues, and other things into the picture.
Also, big “hand waves” are done at various points in my flow, for example, the following things need to be looked at as well
- How is the intake of work managed and prioritized, and by who?
- What is the regression/integration process?
- Who manages the movement of the issue from one area to another?
- How are issues that should not go to the review board handled?
- How does the information go back to the customer?
- How is information distributed to other customers?
- … and so on….
Understanding the Application Lifecycle, really does take “process improvement” to the next level as it allows you to follow several different best practices when it comes to SDLC or even the Organizational Lifecycle; For some organizations, they have a dedicated Business Process Office (or process office) that is responsible for looking at the big picture and ensuring that process is continuously optimized and improved.
So the next time you find yourself, wanting to “improve things” ask your self, “how big” of an impact you plan to make.
Being involved in such efforts right now, I wish you good luck.


