Category Archives: Agile

Agile way of doing things

Agile – Theme, Epics, User Stories and Tasks

Posted on by

Themes

  • A Theme is a key objective or goal which could be across projects and products. Themes can be broken down into sub-themes, which are more likely to be product-specific. At its most granular form, a Theme may be an Epic.
  • Themes can be used at both Programme and Project Level to drive strategic alignment and communicate a clear objective or goal.

EPICS

  • An Epic is a grouping of User Stories that can be logically grouped. Epics are broken down into user stories to detail them out.
  • Epics can be used at a both Programme and Project Level.

User Stories

  • An User story is an Independent, Small, Testable requirement that has clear acceptance criteria and estimate.
  • User Stories are great for Project and Product Development Teams as they are easy to understand, discuss and prioritise – they are prioritised in a product backlog and become part of Sprint as deliverables. 

Tasks

The project / product team members break up the User Stories into smaller Tasks during the Sprint Planning Process to achieve the user story functionality. User stories that are too small may not have a need to break up in tasks.

SCRUM AGILE Project Need and Execution

Posted on by

The world markets and business changes are getting more and more dynamic every day. This leads to continuous business change and expectation to have change deployed in the shortest and fastest time frame possible with required agility and flexibility of business processes.

Given the speed of change and the part Information and Communication Technology is playing we have seen the need for how IT system changes are dealt with and executed. Business is constantly asking IT to make the IT system changes faster and faster while still ensuring quality, cost and time needs are efficiently managed.

A major part of IT system change execution is related to how its programs and projects are executed. The traditional project management methodologies and IT projects water fall method of executing and delivering project outcomes are not helping. The key reasons for water fall approach not working are,

  1. Business changes are dynamic and time to get the change done is shorter means even business doesn’t have the complete idea of every details of the product. Hence requiring faster iteration of part of the product benefits to build on the next set of requirements.
  2. The waterfall method of executing IT projects lead to long project execution cycle that relies on 100% clear business change requirements and detailed product requirements. This requires longer time to get things documented, designed, built and then longer testing, fixing and deployment times.
  3. With traditional waterfall project execution there is lost opportunity for improving the product as the business gets to see the product only at certain stage of the project by when there is not much room for changes given the need for speed.
  4. In traditional waterfall projects the business is unable to make interim decisions stopping the project or changing its path at any stage of the project for better product creation by saving time and cost spending.

The above reasons lead to the need of a new IT projects/programs execution methodology. In 1990s a new methodology emerged called SCRUM which gives the required agility in any IT product delivery. The methodology was more tried and used in early 2000 and last decade by big software development vendors that continuously work on software product development and releases.

SCRUM focuses on products delivery by delivering its prioritised features in smaller (2 to 4 weeks) iterative cycles known as sprint. Each sprint delivers a set of working product features to the product owner for testing and releasing it to production. The whole agile development cycle continues as iterative sprints until the entire product with all its features are delivered to the product owner.

As each sprint (iteration) is of maximum 4 weeks, the product owner at the end of each sprint has authority to approve the next sprint or cancel and stop further product development. The product owner also has authority to change product priorities and add or remove features to the product and hence allowing the agility and flexibility of product development.

There are other positive points of SCRUM (Agile) way of product development. The sprint is delivered by a team working on that sprint. The team has required skilled resources that choose the activities themselves and create a complete sprint plan. The team appoints one of the team members as SCRUM Master who ensures that every single day the team members update each other and SCRUM Master help to remove any roadblocks for a successful produce delivery. The entire team is responsible for product delivery and if a sprint is successful then it’s due to the entire team and when it fails the team notes down the downsides and work on improving it in next sprint.

All in all SCRUM (Agile) way of doing IT projects can be successfully used for all the projects/programs that are planned to deliver products. It’s said that by 2015 at least 80% of IT projects would be using SCRUM (Agile) way of doing projects. So the earlier we start using the better. Even if 70% of IT projects are done in SCRUM (Agile) way then it would do wonders for business change projects.

Application Convergence – What, Why, Who and How?

Posted on by

More then ever the businesses are getting automated and enabled using IT solutions. Every part of the organisation are dependent on one of more IT solutions, some in house and some bought from the market. The IT solutions are made with the need for enabling the business and often leaving the useful ones rest are forgotten and left as legacy/archives to be referred only when needed.

With fast changing business needs applications are created, used and left even faster then we all could think about. Day in and day out business creates document libraries, project team rooms, intranets and a lot more. Over years this turns out to be a huge mess and close to unmanageable. The result is higher maintenance and infrastructure costs. Legacy / archive appls, as they are hardly used result in Loss of knowledge.

In the era of acquisitions and disentanglements to speed up innovation and change business directions, its even more essential to ensure companies have defined and controlled solution catalogue which is well managed and serviced.

For MNCs this is extremely essential as MNCs have multiple office locations, the applications appear like mushrooms in those locations and then grow into a huge architectural and landscape mess to manage and maintain. The issue starts with slight differences in global and local process and document needs. Ones allowed localize the changes continue one after another leading into a fully customized monster application and that too not just in one location but many. The result is enormous costs to maintain, control and change business applications and processes.

Application convergence can be addressed by addressing the following in order mentioned,

Bottom Up Dos

  1. Ensure the As is application portfolio is clearly documented with ownership from IT and business
  2. Collect relevant solution changes and yearly maintenance costs to ensure full visibility
  3. Get the collected data well categorized by business process, functions, platforms, location etc.
  4. Create some data analysis and reports showing number of applications in different dimensions of the categories to be able to see the duplicates, expenditure and other information useful to make decisions.
  5. Ensure the 1st hand bottom up approach analysis and output is shared with the top management and local businesses alike in condensed and relevant manner.
  6. Identify the champions that helped in bottom up approach and they should be used for the application convergence activities going forwards.
  7. Identify the road blockers and how they can be kept in control or convinced that application convergence is good for the whole organisation
  8. Ensure during the whole process that current business and activities are not affected as they will create –ve publicity and barriers for progress

Top Down Dos

  1. At the company level define the Application convergence initiative ensuring full business buy in and management support throughout the organisation
  2. Adapt an Enterprise wide architecture framework (like TOGAF, Zachman, DoDAF etc.)
  3. Start with the Business process layer to define the core business processes. Ensure core functions, business processes are well documented and have clear global ownership.
  4. Short list and select the required architecture and portfolio management tooling as these would be needed for ongoing use, structure, control and management.
  5. Business process by business process start harmonizing the processes and select the best solutions from existing ones or new ones (from the market or built in house)
  6. Focus on quick wins by choosing the valuable but easy transitioned business processes and start filling up the solution catalogue with global solutions. This also means start closing down by transitioning old solution towards new ones and launching them as one global solution
  7. Focus on clean ups that can aid to reduce the infrastructure and maintenance costs and hence result in better use of resources across organization
  8. All new business demands should fit in to new way of working with only one solution at company level.

Another important point to keep in mind is Application convergence in MNCs could take from up to 1 to 5 years although a lot will be achieved in 2 years while the complex applications convergence would require a lot of time and efforts and proper strategic planning to make it happen with business change.

If the above is done in write order with proper management support and control then it ideally should lead to globalised solutions which if made with agile and service oriented architecture would result in agility to cope with business process and tools changes done fast enough and efficiently across the organisation. On the other hand running application convergence will lead to whole IT landscape clean up and steam lining ideally resulting in savings.

SCRUM – Agile Why now ?

Posted on by

We are in a decade where changes of all types and shapes appear from various angles. We all are demanded to adapt as well as deliver successfully on all our activities and task to eventually ensuring the business change request delivered. In the years to come we will continue to face more and more changes and with all these changes comes, risks and delays if not handled promptly and properly.

Amongst all these changes and need to faster, the word Agile and Nimble are heard very often these days. Being Agile and Nimble is all about being lean but at the same time able to handle and adapt to change, growth and even discarding the change when necessary.

For the business change/growth the competitive advantage and window opportunity to be ahead of the competition is getting smaller and smaller. This means if we are delayed for the window then somebody else will take the opportunity and this will result in loss of market share and business growth. This is the key driver for the need of speed in doing so its also key to be able to change path and decide on different routes of changes as they come.

The traditional way of managing changing over years is becoming obsolete given the Gen-X, Gen-Y and later in the decade Millennial coming work. The use of internet for real time collaboration, communication and ideas build up as well as taking advantage and launching new growth options is becoming the name of the game.

The unpredictability of whether, natural disasters and economical changes are putting all business on their toes to react to changes even more faster and to deal with them effectively. Failure to do so have shown business going bankrupt or being taken over by others with in no time.

Even Mergers, Acquisitions and Disentanglements are taking speed where these are more and more asked for be dealt with fully in 3 to 9 months.

All of the above asks us to find out methods and possible ways to handle changes differently then we are use to.

Going towards Agile way of doing things allows us to bring more ownership of actions towards the group of people who need to do it as well as ensure that every sprint the team improves as well as delivers part of the business change requested. Agile is sure shot way of ensuring we are more adaptable to changing routes/options of business, while its not a one size fits all method. This means it needs to be applied and used selectively as it does require efforts and time for an organisation to get used to it and to keep doing it the right way.

Every day Stand Up, Share and Get Going Meetings

Posted on by

In today’s fast paced world with series of parallel changes demanding speed and agility to get things done as a team and individuals. Its essential to develop techniques that allow us to better collaborate with less time and more productivity.

In this article let’s focus on how we can make our progress tracking more effective by doing it in a simple yet effective manner every day/every week. This is also called as Stand Up Meetings. The name stand up is to ensure that people know it’s a short meeting and they need be upto the point, specific and relevant to the group they are talking to.

This has been a very effective method of running progress checks as well as “depending on each other” to keep making the progress we intend to achieve our targets.

The meeting should be arranged everyday/every week at a specific time. As a stand up meeting the overall meeting should be of 15-20 minutes at max. Here is the Agenda of the meeting and Do’s/Don’ts..

Agenda

Each individual member of the meeting has to focus on talking only about following,

  1. What have you done yesterday/last week
  2. What will you be working on today/this week
  3. What roadblocks/issues you see affecting your progress

Do’s and Don’ts

  1. The chair person of the meeting should not be the hierarchical authority. It should be one of the project team member with whom people are very comfortable working
  2. The meeting team should comprise of 2-4 people to be more effective and brief
  3. Every member must prepare what needs to shared and it has to be at max 3 to 5 minutes per person. This also means share things that are relevant for the group and be specific.
  4. The chair person/delegate should record the minutes specially the problems/issues and pass it to the appropriate action driver to ensure those actions are acted on with priority
  5. Focus on ensuring that this does not become a blame meetings(pin pointing) and Ensure it does not move towards highly operations/technical details discussion

Benefits

  1. You will see that all will get use to a very effective and upto point meetings
  2. If done every day there will be only few actions to note and work on
  3. Communication would be crystal clear amongst the team
  4. Team work (depend on each other) will become much more stronger ensuring high level of collaboration
  5. Being short and effective meeting would lead to member’s eagerness to join the meeting

Go ahead and use it. I am sure you will find it very effective too.