Think outside Scrum or Kanban

Today was that day again when I ended up moderating Kanban vs. Scrum process meeting. Honestly was deep into one code refactoring and meeting reminder popup awakened me. Had to quickly gather up myself and started thinking. Why teams always choose one process over other and never ask or understand "what process has to offer them".

Having experience with multiple teams and process. I kind of hate and love Scrum and Kanban. People just like to blame the process vs. putting effort into understanding them. Scrum does not seems to working, lets try kanban.

I wanted them to think out of the box and they keep coming back to Kanban. It's like, I heard it, I saw it and I know I want it. What would be world without waterfall, RUP, Scrum, Safe or Kanban or Lean Startup models.

I was being asked this question long long back and it stuck in my head like a tumor. I myself don't have best answer and always start to think what is a process first before thinking how it can benefit us?

As per wikipedia, it is a series of events to produce a result. In our IT world we can say process helps us to produce software. But how one process does it where as we have each company solving different problems with different set of behaviors in one organization. It's getting late but will think for my new process. Manum may be which will solve next generation problem. May be good starting point would be think of problems which we want our process to solve and pick and choose goodness from all around.

Always like comments
Manisha

Velocity driven Planning vs. Commitment Driven Planning

In my earlier blog, I explained how we should do commitment driven planning. I thought it would be good idea to share why I prefer Commitment Driven Planning.

I would suggest if you don't have experience then try them both yourself. I have my preference toward Commitment Driven Planning.

The biggest issue I face with velocity driven planning, is being predictable. Velocity is volatile. It moves around from iteration to iteration. It bounces around. Again it lot depends upon what your team is doing? Are they developing as well as supporting software which is under constant change. Because incase of less challenging environment you might be able to predict them but in average team environment it is very taxing job.

If I have to take average of my team's last 6 iteration velocity which ranges from 26 to 90 story points. The average is around 35 story points but can we plan 7th iteration with 35 points, is this right amount of work? I tried scheduling work based on our average and failed. I tried doing and taking same approach for next three iteration and failed..

I could not predict the number of story points my team might deliver. Simply because there were lots of unplanned work keeping coming along our way and also team did not think about technical design that well in advance and we failed for numerous other reasons.

Velocity depends upon lots of factor and I think it's variability create more issues vs. helping us. I would love to let my team work at their best potential without thinking about the velocity. Velocity is valuable over long term i.e like building customer profile may take 8 sprints on an average. My team is producing at 35 story points on average but that does not mean they have to product 35 story points every sprint. Over the period of 10 sprint they will produce on average of 350 story points but bringing this much work on each sprint based on this average would not work.

We should always remember the purpose of sprint planning. The purpose of sprint planning is to commit to a set of product backlog items. The purpose is not to come up with the list of task or hours but tasks and estimates are a tools for determining what we can commit to. 

As usual let me know your feedback or if are doing it differently in your team.

Thanks
Manisha

Commitment driven Planning: my favorite

I have worked with multiple teams and each team have their ways to estimate and plan the work in sprint. We can plan our sprint/iteration in two ways.

1) Velocity Driven Planning (VDP)

2) Commitment Driven Planning (CDP)

We all have fairly good idea about velocity driven planning but very few of us do commitment driven planning. My team loves it, so thought of sharing our process.

To start commitment driven planning, team estimate their capacity by simply taking a guess of how many hours of plannable time each individual would be able to devote in the sprint. In subsequent sprint team adjust their time by adjusting the plannable time up or down based on their experience.

What is Plan-able time? 

We all know that if we have to be good corporate citizen, we have to attend some meetings or reply to some HR emails or support our organization ecosystem. This is Corporate Overhead and varies from corporate to corporate. First think how much corporate overhead each individual have. 

The left over should be considered your productive time. Remember productive time may not be always working on planned things. 

Not working on planned thing is not slack or padding or buffer but working on things which can or may occur during a sprint like, production outage, blocker bugs etc. We don't know how this time would be used but team has all good intention to pull work incase Unplanned time is not used. It is a block to accommodate emergency. Look at your sprint and calculate how much time would you need to keep aside for these unplanned activities. 

Left over time is hopefully your plannable time. This time can differ from sprint to sprint and team to team. One sprint they might have lots of support issues but another sprint it might end up pulling more features. Over the period of time it will average itself out.

Once team have the fair understanding about their capacity then team looks at the prioritize backlog. Team will commit to item by item in the backlog. They look at an item, break them into tasks and ask "Can we commit to this". If yes repeat the same process for next item. 

I prefer Commitment Driven planning because team tends to do three things: planning, technical design discussion and product design discussion vs. just planning.

Would love to hear your experience.

Manisha

***Mastery is capability in context 

Process for Art vs. Commodity

I am thinking a lot about process of late. People talk about Scrum, Kanban , XP blah blah. We all agree that none of the process is perfect to solve all your problem. Mostly everybody talk about organization culture, context and business problem influences your process model.

I am not denying about their importance but I strongly believe there is one more factor which is equally important if not more.

Your engineering team. How team feels about writing code? do they feel it as form of art ( I know it's very subjective) or as bunch of functions to complete a business objective? We all write software for business, government or other institution and we know customer only cares about FUNCTIONS.

Question is WHAT YOUR TEAM CARES ABOUT? How they feel about code? Understanding them and their need will be base of any process you put around them.

To my experience if you have a team which treats code as commodity would be happy, following any well define process. Whereas passionate people, who would like to be creative, would prefer little unstructured but responsible system.

May be their own customized personalized Kanban or LeanBan or ScrumBan. First understand the team and then define the process which fits their developer personality.

In my organization one team was very reluctant following any process so we tailored Scrum to their need.

I explained them what Scrum or Kanban or Drum Rope etc process have to offer us. Advantages and disadvantaged of each of them. Then we discussed our issues which we have presently and things my team is good at.

We all agreed that we need something which will let us keep our goodness and will fix our short comings . We designed our own process and my team is loving the process around their need vs. making them process slaves.

I know, I will upset few scrum gurus but my team is happy. To me this is bring agility to process.

Thoughts?
Manisha

Confluence: How to make a page available without signup

I wanted to make a page available to all the employees on confluence without making it publicly available on internet. 

I did not want to add hundreds of account on confluence too. So read little bit and added anonymous user to my space and gave that user a view access. Hoping problem would be solved. After a while realized that I made it available for entire world. 

The started reading more about it and realized that there is a signup option where you can let user access the page without creating the account for them and can also restrict the usage to specific domain only. Look at below screen shot for exact location.

I wanted to write it so don't forget in future :).

Manisha

Tools not rules

Last two weeks were like a hurricane. I had many discussions with lots of people. It was fun and interesting but I stumbled upon few questions again and again.

Tell us about some of the best practices you followed in your team.

I was not sure how to approach? The practices were only best in that context. Which was best for that team might not be suitable for your team. But people love best practices, isn’t it. I think it requires us to understand that calling something “best” might be misleading. I believe understanding, what we are doing and why we are doing, would be more effective. Suggestions???

Another question was “ How did you folks follow Scrum process in your team?”

Very valid question :D, I explained how we started and what was the end state of our team. Mostly I heard, “You did not follow Scrum”.

For example - You did not have cross-functional team. 

My response was, “In that organization the QA was a shared service”. We could not have them full time as part of our team. We could only have them shared. We tweaked few processes, which was suggested in Scrum to make better use of our time. Isn’t Scrum an empirical process? Unfortunately I could not sale our Scrum to them. To me it’s thoughtfulness and common sense to focus more on WHY we must do certain things rather than just following the rules and rituals. But I may be wrong?

Another example - You did not follow story points?

Yes we did not, in that project, the code-base was new to entire team and we start with our hour/days estimate, since team got that right vs. story points. Slowly we got better and started doing estimation using story point. It seems they did not like us deviating from Scrum. 

It is more important for some folks to follow the process properly. Don’t get me wrong! I want to do that too!!! I don't like Scrum buts too? But I am baffled, what should a tool do? Shouldn’t it enhance our ability to achieve a goal or??? I hammer is a good tool for putting nails but might be a bad idea for putting screws.  Every team and environment is different so our processes have to be different too, isn't it? We should always start with prescribed way if possible and adjust as you go. Again not sure whether it’s my understanding of process or tool is wrong. 

Thoughts or comments 

Manisha

org.springframework.beans.factory.NoSuchBeanDefinitionException: No bean named 'cxf' is defined

"org.springframework.beans.factory.NoSuchBeanDefinitionException: No bean named 'cxf' is defined" This error wasted my precious couple of hours yesterday and could not find any blog post pointing to my problem. It seems this problem can occur for various reasons. 

few of them are not including cxf-bundle jar, not having proper cxf.xml files imported into spring context and this error can also occur for the wrong context file. What do I mean by it?

I had below code snippet in my web.xml.

-------------------------------

<context-param>

 <param-name>contextConfigLocation</param-name>

 <param-value>/WEB-INF/spring/root-context.xml</param-value>

</context-param>

My root-context.xml did not have any cxf related definition in it though I was loading the correct configuration file in CXFServlet servlet-mapping. I was hoping while loading the CXFServlet it will use the right configuration file and should work. 

But unfortunately after looking at CXFServlet source code realized that if the global config location is not null then only it consider local location. 

I just had to move my CXF related definition to root-context.xml and BOOM my problem was gone. I uploaded the working sample CXF project under my github repo. 

interesting isn't it

Manisha

How to create a Spring MVC skeleton project in 10 minutes :)

I know it's very simple but have seen people struggling a lot to create and setup the first working project using Spring framework.

Here are the steps to create a Spring MVC skeleton project .

1) Download and Install STS ( Spring Source Tools)
2) Click File -> New -> Project
3) Select Spring Project from the provided list.

4) Spring Project Dialog box would appear. Select Spring MVC Project template and provide the project name.

5) Hit Next and Provide an toplevel package name for your application and choose Finish. 

Believe it or not your Spring MVC application is ready to be deployed on any server. Do look into created projects to understand the pieces involve in it :). 

Happing Spring

Manisha