Enterprise Agile – Are we trying to solve the right problem?

Implementing Agile in a big enterprise is not an easy task. The metaphor I sometimes use for big enterprise is to compare it with Elephant. It's very easy for a small living being to move and maneuver. However when it comes to elephant, it requires time to build momentum and when it actually moves, it moves slowly. People involved in Agile transformation get frustrated because of all perceived delays. Frustration is understandable but not sure if much can be done other than understanding the simple reality that you are dealing with an elephant and not a tiger or mouse.

Now comes other bit. People are limited in their understanding of big elephant just because of their boundaries (silos) in the big environment. Agile transformation in big enterprises might get myopic as most of the people involved are not able to see problems in totality. That translates in focusing issues which require a lot of effort to solve but may not bring the business value you are looking for on board. Some important challenges to consider for Enterprise Agile transformation are as follows:

  • Ability to clearly define the problems in hand.
  • Are we focusing on the right problem?

The big picture could be something like this.

Based on the feedback of the customers or based on market trends, business comes out with an idea or a problem statement which needs to be solved. Now for many technical people, the obvious solution comes as technical solution but in reality solution can be completely non-technical (process improvement) or completely technical or mix of both. Most of the times software development is a part of bigger solution.

The business idea is explained to technology people and they start working on a software project. That's the place where most of the Scrum, XP techniques are placed. Most of the times focus of optimization remains technology. People try to automate everything whatever is perceived as manual step.

However as you move further or before in the value chain, there are other very important steps of solution. For instance after software delivery, change management activities have very important role. For instance deployment to production, training, marketing of the new product etc.

From the inception of the business idea to its implementation and further using it, important components of the chain may not be knowing each other very well because of their implicit boundaries. People try to understand this whole bigger picture but at the end of it many times, they get something like this:

Here's a real story of one big enterprise Agile project I worked with.

In this project Agile was instrumental in delivering the software product in a record time and with tight budget. People coming from waterfall background were very skeptical about it but at the end everybody was happy to see the project delivered within half time of what it could be delivered with waterfall methodology. People were happy and cheered. As project finished, people involved moved on and started working on other projects.

At one fine day I came to know from one of my peers that though software was delivered technically but it couldn't go to production because training logistics will take additional 3 more months. Other than that there were other issues because of which the realistic time to put system live can be 3-5 months.

I was shocked and then wondered if optimizing technical work only should the right focus for Agile teams. Instead of looking at just one part (software delivery) of the whole solution, shouldn't we be worried more on time to market. That actually translates to program management than just pure project management. In this case, if training could be considered earlier as part of solution (program) planning, intuitive UI could be the focus of software delivery. That could lead in the reduction of both training cost and time.

Conclusion

Optimization should be considered for whole value chain instead of just one isolated piece of the chain. Everybody in the team should get the visibility of the backlog required to implement the product in the market and not just technical tasks involved.

Posted in Agile

Custom maven plugin development – plugin execution not covered by lifecycle configuration

You are creating a custom maven plugin, everything works but when it comes to using it in a maven module inside Eclipse, m2eclipse plugin cries with message - "plugin execution not covered by lifecycle configuration".

Now one could find a lot of documentation on how to get around with this error while using a third-party plugin, but what about if you yourself are creating a maven plugin. You would like to fix it before it comes in front of your custom-plugin users.

I was very confused with the existing documentation on how to fix it. So now as finally I fixed it, let me share it with you and come to the point.
Read more ›

Posted in Eclipse, Java, Maven, QuickTip

xml-utilities Library Available on Maven Central Repository

xml-utilities (High level XML Java Utilities APIs) library is now available at Maven Central repository.

Current stable version is 1.0.1. If you want to use these APIs in your project, use following dependency:

<dependency>
  <groupId>com.svashishtha</groupId>
  <artifactId>xml-utilities</artifactId>
  <version>1.0.1</version>
</dependency>

To know more about the library, please read the introductory blog xml-utilities : High Level XML Java Utility APIs.

Posted in github, Java, Maven, opensource

xml-utilities : High Level XML Java Utility APIs

I have been working on Java with XML since 2002. It used to be quite confusing and complex to get the value of a tag for example as it required to get into Node level. Here's an example:

<books>
  <book>
    <title>Book1</title>
    <prod id="33-657" media="paper"></prod>
    <chapter name="Introduction to XML">
      <para>What is HTML</para>
      <para>What is XML</para>
    </chapter>
    <chapter name="XML Syntax">
      <para>Elements must have a closing tag</para>
      <para>Elements must be properly nested</para>
    </chapter>
  </book>
  <book>
    <title>Book2</title>
    ...
    ...
  </book>
</books>

From functional point of view, I may be interested to get book names. So instead of going into familiar low-level Element and Node route, here's what I prefer:

Read more ›

Posted in github, Java, opensource

QuickTip : Github Multiple Accounts Access with ssh

Let's say we have two github accounts named "shrikant-home" and "shrikant-work".

I would like to access both accounts from ssh.

I hope you have already created public and private keys for both github accounts and added in the ssh settings as mentioned at http://help.github.com/mac-set-up-git/

Now create a file named ~/.ssh/config file and make following entries

Read more ›

Posted in github, QuickTip

QuickTip : Editing Gradle Scripts with Textmate

You need to associate '.gradle' extension with groovy as follows:

  • First if not done already, install groovy textmate bundle from http://groovy.codehaus.org/TextMate
  • In Textmate, open "Bundles --> Bundle Editor --> Edit Languages --> Groovy" and change as follows:
    fileTypes = ( 'groovy', 'gvy');
    

    to

    fileTypes = ( 'groovy', 'gvy', 'gradle' );
    

In order to run gradle scripts from Textmate use bundle from https://github.com/alkemist/gradle.tmbundle

Posted in QuickTip, Tools

Building Soft Skills of Agile Team – Key to Real Success

It's easy to work in isolation as nobody bothers you. It still works when you work in cubicle like structures where you speak when you really need to. People need to come to your cubicle to reach you. I may want to communicate through emails even though I know you are sitting just next to me.

Having said that, through experience, we all know that it all boils down to inefficiency, huge time taken to finish a simple thing, long email trails which sometimes never reach to a conclusion, a middle management whose sole purpose is to manage the communication through layers.

Not only software world but also corporate world is moving towards collaboration, no-cubicle culture, team-work and no heroism culture. All that is fine and in general it makes sense also, but as professionals are we prepared or trained on how to deal with humans or different human behaviours? While working with many Agile projects, I could see that problem hindering project success is not essentially technical but soft skills. Agile promotes pair-programming but doesn't teach on how to deal with certain individuals or the way they work.
Read more ›

Posted in Agile, Agile Adoption, Opinion, People Management

How to break requirements into user-stories

It's easy to talk in terms of the user-stories but when it comes to create them, it may be a daunting task to break features into smaller functional chunks. This is not very specific to Agile only as the same can be practised in Waterfall projects too. There it helps in identifying and prioritising the smaller chunks of the functionalities which essentially provide business value within short span of time.

Context

The presentation is mainly for people who are moving away from waterfall and adopting Agile. The problem is changing the functional-specification specific mindset into one which could think and appreciate smaller functional chunks. For these people, thinking in terms of smaller user-stories becomes a challenge. This presentation aims to help them. At the same time, it's useful for people who already work in Agile projects.

Read more ›

Posted in Agile, Agile Adoption

eclipse-to-maven : Printing Dependency Tree of Eclipse projects or Workspace

Many a times when you need to understand or optimize the dependency tree in Eclipse projects, it's simpler to look at .classpath file or at the build path of Eclipse project. However it doesn't remain practical for a big workspace as .classpath file contains many other things other than <classpathentry/> tags and also you have to open individual .classpath files in different Eclipse projects. Looking at Eclipse buildpath becomes too repetitive and mechanical in a big workspace.

eclipse-to-maven project supports the functionality to print the Eclipse dependency tree in readable format. The steps on how to use this it are mentioned in the README of the project.

Posted in Eclipse, eclipse-to-maven, Tools

Converting Eclipse Workspace to Maven – Why eclipse-to-maven?

Through this post, I would like to analyse the factors on why to mavenise the existing Eclipse based workspace using eclipse-to-maven project.

Focus on business goals instead of just doing build

ANT is a low level language and requires everything to be created from the scratch. The main focus remains creating build for the project. With Maven, build becomes trivial and you start focusing on bigger goals like enforcing test coverage, static code review with checkstyle and PMD. That too becomes very simple as many of the plugins are already available.

Good opportunity to restructure

Provides a good time to restructure and having a thoughtful analysis on what kind of sources should be placed where. The analysis results in potentially removing cyclic dependencies, identifying the sources which are not used anymore. This in turn results in reducing the build time significantly.

First step towards continuous delivery

In order to be continuous delivery ready, the build has to be single click (virgin machine with just Java in place), continuous integration ready all the time, plugins available to support automated functional testing. Also build should be simple enough to introduce any new small or big build specific change. Maven is a first step towards doing that in any Java based workspace.
Read more ›

Posted in Eclipse, eclipse-to-maven, github, Java, Maven
Welcome to Sampreshan
Technology Strategist, Speaker, Scrum/XP/Agile Trainer Coach and Trainer
Your interest areas
Follow

Get every new post on this blog delivered to your Inbox.

Join other followers: