Methodologies

SCRUM : Why I like it so much


Scrum. It’s that point in the game where the guys all get together to discuss the finer points of ball management. They set a plan, huddle together and execute.

That’s not a million miles away from SCRUM, that agile software development framework that IT professionals use to execute and keep track of IT development projects.  I like it, because its simple and the status of the project is clear at any point in the iterative cycles.  There are little rules in SCRUM, but its a clear and to the point framework.  The whole point of scrum is to ensure that regular iterative cycles called sprints are undertook and at any point in those cycles the state of the development is made clear, usually in meetings that have the team stand, which so far, I like because they last about 15 minutes max.

The general flow of a development project being conducted with the SCRUM framework applied would look like the following:

Set a SCRUM Master (basically the project manager / project leader). Work with your subject experts and business analysts to identify a worklist and set of features the product being developed is to include (normally based on the functional requirements). This work list is commonly known in SCRUM as the product backlog.  Based on the finalized backlog, work with the development team to order the product backlog in priority order.  In my experience, this happens following some work with general architecture design of the product, so lots of UML diagrams and talk of design principles and patterns by the lead Enterprise / Solution Architect(s).

Once the order of work has been set, the product backlog is split up into sets of ‘sprint backlogs’ which illustrate the list of tasks to be performed during each ‘Sprint’.  Sprints are the iterative development cycles and tend to range in time between 2 to 6 weeks or so (at least in my experience with SCRUM).  The aim of the sprint is to have an area of the product in a ‘ship ready’ state by the time the sprint ends, so that should mean that the unit tests have been carried out and the QA guys and gals have signed off on the work.

During the sprint, daily team catch up meetings (huddled in headlocks of course 😉 take place to ascertain the state of play each day.  Being open and transparent in these meetings is the key to ensuring the sprint will finish on time.  In the SCRUM meetings I have taken part in, there is generally a rule within the team that there is no bad news, just be clear and no friction will arise.  No one care’s if you’ve not finished something, just be honest so the team can handle it during the current sprint.  In my experience, a playback of development to the customer occurs at the end of each sprint.

The workload and project timeline is normally set out against the burn down chart. This is a popular diagram with project managers / Scrum Masters because its a visual indication of whether the project is ‘burning down’ enough to land the project on time for delivery.  By understanding in advance whether the sprints are delivering, you can understand whether additional resource or cost injection is needed in order to finish the work in the timescale agreed with the stake holders.  There’s nothing worse for a project manager or programme manager than being grilled by the board because a project is over run and over budget.

I’ve certainly had my fair share of involvement in projects that have overrun and have gone well over budget (who hasn’t 😉 and these are non SCRUM projects.  I’m a fan of SCRUM because of its honesty about each sprint’s state of development.  You know exactly where you’re at every day and because everyone does tend to stand in my experience (you don’t have to), people are quick to update and get to the crux of matters because they wan’t to sit down. This leads to quick identity of issues and resolution of those issues.

I’m a fan of SCRUM and I’d love to hear about projects implemented using this framework that have been delivered both on time and within budget… Comments please!

Oh and last but not least, Happy New Year!

Advertisements

Scrum in 10 minutes


I’m not too far from kicking off a new project using SCRUM as the agile approach. SCRUM is a relatively well know flavour of the AGILE (moving quick and lightly) project methodology for software development.  One of the best quick and dirty summaries I have ever seen on youtube for describing the scrum approach is Hamid Shojaee’s SCRUM in Under 10 Minutes.

The vid is a great explanation of the approaches and tools that SCRUM offers and Hamid takes a great visual approach to the teaching (which for me as a visual learner was a great experience). The added bonus is that the video is also in HD.

You’ll be a SCRUM expert in no time!

Jargon Explained (Quickly!) : Frameworks, Methodologies, Models.


So not too long ago, someone asked me what I know about the ‘Zachman Methodology’ and the ‘UML Framework’?! – It got me thinking that all of these enterprise architecture terms and their respective ‘technologies’ can confuse a person; what exactly is a methodology or a framework and what approaches are classified as what?

Each time some new group of companies comes up with a new approach to software / process modelling, IT project management and their position in the overall enterprise architecture model it gets even more confusing for the man in the street.  Acronyms such as RUP, UML, TOGAF and SCRUM (well, this one isn’t really an acronym) can be found on CV’s the world over and are closely tied with IT infrastructure and software development projects.  What I’m attempting to offer in this quick article is some separation and understanding of some of the common frameworks, notations and methodologies relating to both business process and software development in an enterprise. I don’t claim to know them all, but I’ve experienced ZACHMAN, AGILE and UML via projects I’ve worked on which sparked my interest in the more pragmatic and structured view of BPM/EAI and Software planning and development.

What’s what?

What we mean by Framework, Methodology and Models/Notation. I’ve nicked what I feel is the most comprehensive definitions from one or two well known ‘wiki’ 😉 sites (plus my additional comments):

Framework : A basic structure of support. Basic indeed!? – In terms of traditional building architecture, the framework is the mechanical structure of the building.  In software design its more of a conceptional foundation for solving a particular software problem.  The .NET framework for example is named so as it forms the basic class structure and rules that allow software to be rapidly built and executed in a secure way on the Windows platform.  Zachman is the framework for the architecture of an enterprise (more on this in future articles).

Model:  A diagram representation of a physical or conceptual ‘real word’ object. Frameworks (structures) of all kinds can be broken down and described in detail.  Physical or conceptual idea’s are best described through images with descriptive notation or ‘Metadata’ (data describing data).  In traditional building architecture, blue prints are the model used to convey what conceptually needs to be built – it contains detailed information about sizes, materials and relative positioning (the model’s metadata).  In terms of the structure of the world, maps provide the model to getting around and understanding distances etc and in software development, models describe the classes, objects and information that make up the desired software solution. It’s important to note that models not only describe the framework / structure of something but the way parts of that thing interacts (the behaviour).  Creation of models (or modelling) pays a large part in the planning of anything and in terms of an enterprise, the planning of business processes and software development amongst others.  UML (Unified Modelling Language) is one of the more well respected, widely used and popular modelling styles (albeit not without its share of criticism) and is used to model software behaviour and structure and business processes.

Methodology: A system of principles, practices, and procedures applied to a specific branch of knowledge. In terms of enterprise architecture, this describes the principles, practices and rules to delivering an enterprise project which ultimately supports the enterprise architecture model and the business model in general.  It’s an approach on how parts of the enterprise architecture should be planned, developed and monitored.  All projects tend to follow a particular type of ‘methodology’ that best fits with the desired results. Agile and Six Sigma are applied methodologies for software development and business process projects.

UML : The 4+1 View of a System


UML Title

A little about UML

UML is a Standard Modelling Language for system design. It allows for the visual modelling of business processes, software and systems and is made up of:

– Notation (Symbols, Connectors, Notes and Values)
– Diagrams (The visual make up of a system).

UML is a set of specifications managed by the Object Management Group (www.omg.org). UML is extensible and it has been designed to be flexible and scalable (UML can be used to model a huge system or a quick business process sketch). UML can be used to model the following:

– Business Processes
– Application Structure
– Software behaviour (workflow)
– Model data structures
– Sketch out general structured idea’s
– Communication workflow
– Deployment workflow

The technology evolved from object orientated system design using classes and objects as the basis for components of the workflows. This concept is not only applied to programming however, business processes are made up of components that can be represented as objects. Lets cover some Object Orientation basics…

What is a system?

A related set of objects and instructions that together provide a working process.

What is an object?

Something (a component) that exists in the context of a system. An object is an instance of a class. A repeat product of a prototype / template idea (Class).

What is a Class?

Classes are templates that can create objects.
Classes have attributes (properties) and Methods (how it operates) associated with them that allow object instances to use.
Classes can inherit properties and methods from other classes, this is called class inheritence.

Relationships : Object Orientation

Created Objects do not always exist in isolation. They have relationships with other objects (ARE ASSOCIATED). For example, a speaker object and cd player object are working in associated to provide you with music. In the example of a fish bowl, The bowl object has a relationship with each individual fish object.

Class:Basketball Player
SubClasses:Center, Forward, Guard
Methods: Dribble the ball, take a 3 point shot.
Properties:Black Shorts, White Shoes.

Each object created from the subclasses hold a relationship with other objects in that they work together as a basketball team.

The 4+1 approach to modelling systems

When looking at an entire system as a whole, it can seem complicated at first and a good starting point if to create a 4+1 model diagram by breaking it down into 5 parts or Views. This model ensures you have considered and documented these 5 high level important aspects of any system. This approach breaks down the modelling of any system into the following views (inclusive of a use case view):

UML - 4 plus 1 System View

Each segment of the above offers its own perspective on the system architecture. Each of these views are clearly offering different information and so each view has a different UML diagram associated with it.  As you can see its made up of 4+1 parts:

Logical View : The logical objects (parts) of the system.
Process View: The process (workflow) of operation of these objects.
Physical View: The physical hardware and software the systems runs on.
Development View : The packages, run-time environments and class libraries used.
Use Case View : What the system does (functionality) from the perspective of a user (scenarios). Used in combination with requirement / specification documents.

Lets break these 5 system views down some more:

Logical View (The Systems Objects)

This view shows the components (objects) of the system as well as their interactions / relationships.  So effectively is the object model layout. It comprises the classes and objects within the system. UML diagrams that illustrate a systems logical view include :

– Class Diagrams (Most common UML diagram)
– State Diagrams
– Object Diagrams
– Sequence Diagrams
– Communication Diagrams

Process View (The Systems Workflow)

The process view shows the processes / workflow rules of a system and how those processes communicate with each other. It explores ‘what needs to happen’ in a system. UML diagrams that illustrate a systems process view include :

– Activity Diagram

Physical View (The System Environment)

This view shows the systems execution environment (hardware / software platforms). UML diagrams that illustrate a systems physical view include :

– Deployment Diagram

Development View (The Systems Software Hierarchy)

This view shows the parts of a system used in its operation (its layers of operation). It gives a building block view of the system. For example Packages Used, Execution Environments (i.e JVM or .NET), Class Libraries and Sub systems utilized. UML Diagrams that illustrate a systems process view include :

– Component Diagrams
– Package Diagrams

Use Case View (What the System is supposed to do)

This view offers an outside users perspective of the system. It captures the goals of the system and looks at the desired functionality of the system. Used along with use cases (user requirements / specification documents that the business analysts generally write) to understand the systems required use / functionality. UML diagrams that illustrate a systems process view include :

– Use Case Diagrams

Six Sigma : The Birds Eye View


Six Sigma is one of those buzz words that company management teams tend to throw around. It may sound like high level tosh, but its actually one (if not THE) most respected methodology for improving business processes with the aim of increasing business revenue and competitive advantage. There are lots of useful examples of companies who have deployed a six sigma project and have their processing running at six sigma. So what’s it all about? In this article I attempt to give a 1000 foot view of what it is and try and explain what it can do for an organizations processes. Remember though that this isn’t nearly enough information to understand it completely. There are courses for becoming practitioners at certain belt levels and it can all become pretty costly, however recorded results and ROI have recognised that this methodology works.

So what is it?

Six sigma is an applied methodology (organized collections of methods/activities) for improving business process performance. It can also be seen as a problem solving methodology for minimising the amount of errors in a business process out of a possible opportunity for errors. It started in the manufacturing sector with its creator Bill Smith working at Motorola back in 1986. A process that performs at six sigma is extremely efficient and experiences only 3.4 errors per million error opportunities. That’s quite a target to achieve, so efficient that the statistical analysis of a process is required to locate every possible point of defect, that’s why a six sigma project generally produces substantial improvements in process and why its known as the THE best process improvement methodology.

Since a six sigma deployment project aims to gain such efficient processes, it effectively maximises the value of the process output (remember a business process is just one or more inputs, a collection of interelated activities and a value added output). A six sigma deployment project will use a plethora of different tools to analyse business process data at a detailed level. What I hope to convey in more detail in future articles is the stages of a six sigma based project, the roles and the tools for each stage of the project. Finally, the key point to remember is that EVERY organization needs to improve in order to obtain the competitive edge (against other improving competitors).

The project generally has two levels to make it work. Managerial and Technical. The technical roles will be responsible for the physical transformation of a process based on the information gathered. The Managerial level is where the project starts, it must have managerial buy in and be driven from the top of the organization (or business area), not hugely different from most business critical projects.

Management: Management must understand that the project will provide them much improved ROI (one of its biggest focuses) and also its customer focus (since for most businesses, the output of certain process may benefit the customer directly). Finally, management should be taking accountability for the project and leading it, including organizing the structure of deployment, the strategies and tools that are to be used and who will take on which roles (belts in black, green and yellow).

Technical: The technical portion is the definition (D), analytical study and measurement (M and A) of the ‘as is’ process and the improvement (I) and control (C) of the ‘to be’ process (DMIAC).

Variation

Each part of a process output (i.e a service, a product or transaction) has characteristics that are generated as a result of the process. It’s looking at these characteristics that results in ‘component’ improvements. Improving the individual characteristics of each small component part of a bigger product, service or transaction is what results in a larger scale improvement in the end result. Each time a business process runs, its component parts (and their characteristics) don’t generate exactly the same output each time and together with all other parts of the process this can result in defects in the processes end result. Each ‘difference’ in component processing is known as variation.

Let’s take the production of a teddy bear, each bear could roll off of the conveyor belt in a slightly different form to the previous. This variation could be a result of variations in the way the bear’s nose is
attached. Understanding the variations is the key to change. As component defects multiply, the percentage of overall error is large (especially if one component of the process is dependant on another, compounding defects). Variation happens naturally as a result of cause and effects, its a case of managing or controlling that variation to produce really efficient processes. One important point to note is that variation can change over long periods of time, therefore short term variation and long term variation should been seen as different (variation may increase as a higher rate over time for example).

The Sigma Scale

The scale is the measure of how well a component characteristic performs against its requirement. The higher the sigma score the more capable the characteristic. If a component for example, lets say our bears nose assigning machine has a defect rate of 31%, then it is operating at two sigma. The goal of course is to up the operational accuracy and lower defects to a 0.0000019% defect rate, or for the process to performance at six sigma.

Six Sigma Chart

The Six Sigma Equasion.

Y = f(X) + E

or in simple terms, Process Output (Product, Service etc) = Component Function (Functions Inputs) + Defect Variable. Simpler again, a certain set of process inputs is transformed by a process component and together with its known variations generates a process output (with or without defects dependant on the variation variable). The DMAIC process can improve

DMAIC Methodology

Define, Measure, Analyse, Improve and Control are the technical systematic methods of the problem solving process. The DMAIC stages can improve any type of process in any organization, increasing  its efficiency and effectiveness. The ‘Define’ stage deals with setting the context and project objectives. ‘Measure’ is the stage for getting the baseline performance for the process to be improved. ‘Analyze’ covers using a selection of tools to understand the cause and effect relationships in the process. ‘Improve’ is of course the roll out of modifications to the process and finally ‘Control’ is the stage at which plans are put in place to ensure that improved processes are sustained.

The DMAIC methodology is performed by trained practitioners and ‘tollgates’ are met. As one tollgate is completed, the next one can be tackled.

Six Sigma DMAIC

As I mention, performing these stages can include a lot of detail along with a lot of available tools to perform them. I’m not getting into that here as its far to much to go into, but there are lots of great Six Sigma resources on the web along with a great little iphone application that covers the tools and methods available to each of the stages in te DMAIC methodology. Pop Six Sigma into itunes for more information. There are also certification programmes for each of the belt levels that train individuals the tools and methods involved in the DMAIC process. Read a lot about six sigma and then get involved in a six sigma based project.