ScruXBan as Execution Tool Within the ALT+F Framework
ScruXBan as Execution Tool Within the ALT+F Framework
Join the DZone community and get the full member experience.Join For Free
In my previous post I introduced the <ALT+F> framework. I mentioned how the framework moves withint the MAPE (Measure, Adapt, Plan and Execute) lifecycle.
If, during the Measure phase, the <ALT+F> templates show poor IT Operations performance, the next steps in the Adapt and Plan phases are to identify optimal targets to achieve operational excellence and best-in-class status and then to set the stage for an Agile and Lean transformation strategy that should be executed on two levels:
- On the organisation level, the transformation strategy should educate people on both sides of the fence (i.e. business and IT) to what it means working in an Agile and Lean environment. This will be the topic of another post.
- On the operational level, the transformation strategy should make use of Agile and Lean methodologies to streamline IT Operations, eliminate waste and maximise business value delivery.
In my book on <ALT+F> I introduce a new IT methodology called ScruXBan, which I believe helps IT organisation maximise the business value they deliver. Before entering into the details of this methodology, we first need to ask ourselves what are the common problems that IT departments face. This analysis is the content of this first article. In the next article of this series, I will describe in detail the ScruXBan methodology.
From my experience, the most common problems that cause poor IT performance boil down to the following aspects:
- Too much time goes in unproductive activities, what Lean defines as waste, i.e. any activity for which customers wouldn't pay.
- Gated processes. A typical example is represented by the Waterfall methodology which demands that before moving to the next SDLC phase, a formal sign off should be obtained for the phase currently in progress. So, for example, before moving to the Design phase, requirements should be signed off.
- Early commitment. A super set of the previous point, early commitment is a lot more widespread than one might think. By early commitment, I mean the requirement to take unmodifiable decisions early on in the process. Pre-emptive IT methodologies, such as Waterfall, are a case in point. By asking various stakeholders to commit early to a certain phase in order to move to the next, we're asking for early commitment. However early commitment does not only apply to gates. We witness examples of early commitment in all phases that accompany an IT system from inception to production: the request for a precise delivery date, the decision of implementing a system in a particular way, the need for up-front budgets, the constraints imposed by contract negotiation, requirements specifications, the specialisation of certain people in certain roles (key-man dependency), etc.
- Top-down management instead of grass-root leadership.
- Considering offshoring simply as a way to save money, rather than an opportunity to introduce diverse skills in a team. How many of us could honestly say that offshore resources are treated as first-class IT citizens? And, conversely, how many of us could honestly say that we're not delegating to offshore teams repetitive and not-so-challenging tasks such as Quality assurance (QA) or maintenance?
- The lack of access to business resources. Too often, developers are organised as if they should only think within the box, do what they're told, just deliver the task. What happened to seeing the big picture, experimenting and looking at development as a learning exercise? When stuck in such a restricted way of looking at the development activities, there can't be a favourable environment that promotes a dialogue between the business and IT and then two things normally happen: IT starts taking decisions for the business and the business starts loosing fate in IT, which introduces us to the next point.
- Lack of trust and communitation barriers between the business and IT.When we, as leaders, don't foster an open communication between the business and IT, don't place the business at the centre of the process, don't see IT departments as a service to the business, we're actually promoting an environment that eventually leads to a luck of trust and communication between IT and the business. We're all supposed to work in the same team,but punctually we tend to do anything in our power to accentuate the split between who is supposed to drive the requirements (i.e. the business) and who is supposed to deliver them (i.e. developers).
- Lack of attention to the quality of software deliverables. Too often, developers are only focused on gettings things done, little thinking goes to the quality of what's being delivered. If not properly coached, this attitude might result in false positivies, i.e. the perception that things are getting done until that time when they reach production. This is when the lack of quality really shows not only in the form of production bugs, but most importantly, as an avoidable cost. It's our responsibility, as IT leaders, to make sure our teams see the big picture and understand that the cost of production bugs, what in <ALT+F> I describe as CPB, increases the further we move away from the initial SDLC phases. It's our responsibility to educate our teams to think of quality long before thinking of speed. Sometimes the obsession with speed is fostered by the business who wants to see results. It's our responsibility to educate the business to the benefits of delivering high-quality products because if we fall in the trap of just giving the business what they want, our organisations will pay the price later on.
In my next article, I will describe how these common problems are being addressed and then I will introduce the ScruXBan methodology as an alternative to the current ones being used in the majority of cases.
Published at DZone with permission of Marco Tedone , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.