Agile Events Calendar

My team maintains a calendar of Agile events in New York/New Jersey as well as webinars and other events and training opportunities available to Agile practitioners. Hope you find it useful. Please post any suggestions for improvement as well as any additional events  in Comments so that we can benefit from this knowledge sharing opportunities together.

The Mastery of Lean Startup

The concept of Lean Startup introduced by Erik Ries is an amazing collection of common sense and  innovative ideas. If you have not seen his Google talk or read his book on Lean Startup, my advice for you is to stop reading this blog and watch this video instead. My Agile team at work has our own Book Club, and the last three sprints, we are reading Erik Ries' book, and each time we find a lot there to admire, and about as much to disagree with. Some ideas resonate with me (validated learning, minimally viable product, pivoting once your assumptions are invalidated - all makes perfect sense) while selecting a small group of customers to validate your product and make decisions based on this restricted subgroup does not.

I value contradictions. Primarily, I do so because I do not believe that they exist. I treat them as puzzles for us to solve. So when I got a qiestion whether I would want to go to Lean Startup Machine Training in New York, I said "yes" without hesitation, even though I had no clue what the training is going to be. And once I did, I found that it is all-weekend training which starts on Friday evening and ends of a Sunday evening, and goes almost non-stop for all three days. It is a hackathon-like experience for entrepreneurs and for anyone who wants to learn how to start building your product right. The concept of working through the whole week-end slightly scared me but not enough to pass on this exciting opportunity, so I rolled my sleeves, checked into a hotel in New York and started the 3-day marathon.

Now that the second day is over, I want to share my thoughts with you while the experience is still fresh.

First, it is worth doing! Learning about lean startup is nothing compared with going through it. Powered by a simple yet powerful product envisioning tool called validation board, my team started with building a fee-free tool for business professionals who need to find company after work hours while on travel (at that time, we were thinking of social activities or just a friendly chat) and after 5 pivots and a lot of interviews of potential customers, we have designed a VIP Travelers Club with a $5K/year membership fees. Interesting that our first idea had a very low conversion rate while the final one brought us an advisor who wants to introduce us to an investor. You never know your customers until you ask them directly! This is my learning experience #1. And the second one is similar: "go out"," "talk to the people". My two teammates - Hao and David - and I spoke a lot to the strangers and learned that the first product that we loved and voted for has limited business value while the final one has a significant business potential.

Why am I telling your this? - To encourage you to get out of the building, meet your end user, validate your assumptions and pivot as many times as you need until you find a perfect combination for your Minimally Viable Product (MVP). And once you did, validate and build over again. This is how all successful product owners create their winning products.

What is in common between performance review and planning poker?

My team of coaches meets once a week for a very special ceremony we created called CPI, which as you know, stands for Continuous Process Improvement. It is our opportunity to talk to each other about our findings, things that work, parking lot items that we would never prioritize for other meetings, and just to spend time with like-minded people. We agree, sometimes disagree, but it always feels good like the time worth spending and the inspiration for new exciting thoughts, approaches, techniques, and just the energy you get when you talk to people who have similar values to yours.

But this posting is not at all about our CPI time. The reason why I wanted to mention this atmosphere of mutual respect and complete trust is that I and my colleagues were talking about maintaining relationships with Agile practitioners as an organization, and I spoke about cultural differences. I mentioned that when I came to US as a student and someone would ask me "How are you doing", I would start telling them how things were and thinking that they asked about they are genuinely interested in knowing the details - otherwise, why would they ask? (I did not mention it to my colleagues, but interestingly - and I think it describes very well the atmosphere of Stanford University in mid-90's - it took a few months before someone explained to me that this is not what was expected. During the first two months or so everyone listened to me and nothing challenged the impression that people genuinely cared. And maybe they did, just considered me weird, but still cared - hard to figure out now.

Two things happened to me recently that revealed interesting similarities. One - I have been conducting annual performance review meetings with the scrum masters who report to me as their functional manager (we have a matrixed reporting structure, and my role as a functional manager is to develop scrum masters from Agile best practices standpoint and in terms of their career growth, support them, and through them support our Agile teams). I collected light form of 360 feedback - from teams, business stakeholders, Agile community, and shared my summary with each of the scrum masters. Scrum Masters felt these conversations were helpful. They were helpful for me, too.

However, a popular perception is that if we have trust (which I hope we do) and provide open feedback to each other on an ongoing basis (which I know we do as well), then annual performance review are not needed. At some point, I thought the same way. And then, my attitude changed. Each of these conversations triggered a really great discussion - discussion about goals in life, difficulties that they overcame, achievements they are proud of, dreams for the future and for their teams. Each of the conversations was rewarding and energizing. A simple topic related to teamwork would reveal challenges and victories, and we would talk about how the team is gelling together and what we can do to help the team achieve higher productivity and joy in their work. It is like answering with your biography to the question "How are you doing?", and this biography is so meaningful and relevant that you do not want this person to stop, even though it is not what you expected.

This morning, I read December blog posting by Dan Mezick in his blog. He was talking about estimating as a team learning experience, and he spoke about Planning Poker. He said that the Planning Poker is not meaningful by itself, but as a ritual and a team-learning effort. I agree with Dan: planning poker's value is in that it promotes conversations about complexity, unforeseen pre-requisite, configuration changes no one anticipated, and other relevant tasks. Similarly, annual performance review. Even if the information presented in it is not new to the participants,  there is a  value of having it, because

---- and this is what there is in common between both -----

both are powerful triggers. Annual performance review triggers important conversations between employee and his/her manager, it makes us think of what has been achieved during the year and how to become better in what we do. The secret is: don't try to use this ceremony (isn't it a ceremony in scrum understanding?) to assess individual performance. Similarly, the planning poker triggers story discussion for the team, where new and unforeseen things may be discovered that will add complexity to the story, but don't expect the estimation to be accurate. Both may serve a different that their stated purpose (which is for performance review to assess performance and for the planning poker to estimate), but both are very helpful and important. Same goes for answering the "how are you doing?" question - now I get it :-)

Commitment vs. Forecasting

I believe in simple human values. That is why I call my blog "scrum with a human face". You probably noticed that I write less about processes and more about people with their feelings and perceptions. I am not an idealist. I cannot even figure out where people worked harder - at my previous employer who did not care about people or at my current employer who cares about people a lot. But I definitely know where people are happier and this is sufficient for me to make a choice. You can call me old fashioned but I still believe in promises, happiness, and good will.

You may argue that promises are broken so frequently that the value of the concept is dying. Maybe it is, maybe not, but I think it is values not processes that made Agile such an incredible framework. What resonated with you that you first heard about scrum? Sprint planning and sprint review meetings, or values of respecting people over processes and collaboration over documentation? Anyway, I am not writing this blog to remind you of Agile manifesto. The reason I am writing it is to talk about the power of commitment.

I do not know if it is normal to break promises nowadays. Some people do, of course, but are those people your friends? someone you respect? someone you want to interact daily at home or at work? There is still respect for those who keep their promises and I think each of us does our best to meet our commitments, even if it is difficult sometimes.

In scrum, it may be impossible to meet a commitment sometimes. Having that said, it is important to do two things:
1. As soon as I understand that I may be not able to meet my commitment, I make it transparent to the team at a stand up or as soon as I know. I ask advice from my team members or ask for their help. In about half of the cases, this works!
2. If there is an external dependency (data not available, tool not procured, environment issues, or dependencies on other teams), I ask for help from my scrum master, research workarounds and short term solutions (mock up the data, try a different tool, etc.) and make the other party aware that they are a blocker for me asking whether they can suggest an alternative solution. In my team, we use a physical task board, so we put those dependencies on a different color stickie. When stories have a large number of blue stickies (external - outside of the team - dependencies), we estimate it higher because it normally takes longer to resolve.

So - when at Agile Day NYC 2012, Ken Schwaber spoke about the update to 2011 scrum guide to replace the concept of commitment with the concept of forecasting, it did not resonate with me. Please do not misunderstand me - I respect forecasting, it is important, and that's what we do every sprint. But take commitment out - and it is almost like saying "let's not give promises because people don't keep them anyway". But some do - and this makes this world a better place.

There are many good points in talking about "forecasting" - a great posting on the topic is here, so I am open to comments and other thoughts.

In my next posting, I'll talk about another "scrum with a human face" topic - how to achieve balance between referencing impediments during a sprint review sessions and finger pointing.

Scrumban in a Nutshell (Part II)

In our PMI presentation, Irina and I spoke about a single team's journey from waterfall to scrum to scrumban. Transition from waterfall to scrum for a project like ours which had fluid business requirements, which were discovered as we developed new functionality and provided sufficient data for re-engineering and creating new business rules, was natural. It eliminated frustration from the business stakeholders and increased team's moral, provided business results that were needed. But it was not the end because once the team established repeatable rhythm, it became clear that planning was a challenge, and the old problems we thought we successfully overcame with transitioning to scrum, came back. 

At that time, I have not read Corey Ladas book on Scrumban yet, nor was I familiar with a brilliant definition by Yuval Yeret that Scrumban takes scrum outside of its comfort zone, but we felt that we are producing waste and at the same time, throwing in too many stories we are unable to complete, our planning was obsolete before we left the planning session, so it was clear we had to become lean. So the concept of scrumban emerged for our team as an attempt for lean scrum. 

While attempting to go lean, we did not want to sacrifice the rhythm that we achieved and the cadence we established  Business stakeholders enjoyed the demo and appreciated knowing when enhancement requests will be worked on. The team liked the concept of set iterations and repeatable ceremonies. So, we wanted to keep scrum cadence and become more lean. Scrumban became our answer.

So, to reiterate, our objectives were:

1. Keep the cadence of ceremonies - sprint reviews and retrospectives were the two practices working well for the business stakeholders and the team.

2. Set up clear objectives - having a goal is natural for humans. Without meeting specific objectives and no goal to achieve, work becomes dull and besides, there is no reason to celebrate!

3. Deliver prioritized work to the customer - work has to be prioritized, discussed and agreed upon. Maintenance requests include fixes and enhancement, and some of those enhancements are critical to the business, so "first come first served" approach does not work for them.

4. Minimize waste - no reason to do planning if the inflow of stories is high, and prioritization is the hey. No need to plan if it becomes obsolete before the team leaves the planning session.

5. Provide flexibility customer needs - ability to shift priorities as new stories are submitted.

6. Minimize work in progress - avoid overwhelming your team members with dozens of urgent requests in flight. This becomes stressful and unproductive due to context switching and frustration that incomplete work creates on both sides, so the idea was to establish a flow and minimize work in flight for the team.

As you can clearly see the first three goals map to scrum and the second three map to kanban. By adopting scrumban and customizing their workflow to the specific needs of the business system created, the teams were able to provide better visualization while providing visibility the users needs and objectives the team committed to. Here's the team's scrumban board:

For a good summary on how scrumban combines scrum and kanban, I would recommend this brief yet informative posting.

There is much more to it because we haven't yet discussed measuring progress and forecasting in scrumban. Post a Comment if you'd like to talk more about it, and we'll continue the topic!

Scrumban in a Nutshell (Part 1)

Scrumban is becoming  a buzzword, and if you ask me, for a reason. People like structure. We are cyclical creatures. We set goals, work on making them happen, and set up a new set of goals. We need a direction to go and a sense that we will get there. Who hasn't ever set up New Year resolutions? We are in the beginning of the February and my personal ones are fading already, but I still remember a nice feeling of setting them. How does this apply to Agile? - you will ask me. This is why I think it does.

Last week, my colleague Irina Miretskiy and I made a presentation at a New York Chapter of the Project Management Institute about our case study. The project we worked on started as a very traditional waterfall project. The goal of the project was to create a reporting system for a company which was in the process of changing its business model. Reporting functionality included application of multiple business rules to slice and dice and shape up the data to model how the business is structured. The complexity was that in the middle of transformation no one understood yet how the business would be functioning. Just one example: image student enrollment in a test prep class. As a Sales manager, you need to assign a sales credit to a sales rep who signed up a student (or as an alternative, you can roll up all sales for a physical test prep center and split the enrollment credits based on a set of specific rules). However, if you are switching to an online model and your classes are no longer associated with a physical center, how would you be able to track student enrollments back to the on-campus sales rep, an online ad, or a free test prep session that the student attended in college? In most cases, business rules are so complicated that they have to be re-engineered based on common sense.

This was exactly where the complexity of the project was. In slicing and dicing the data, in aggregating enrollment, sales, marketing data based by dozens of parameters and decision points, the team approached desired data accuracy one steps at a time on a thousand-step journey. Each step looked like "come up with the business rule" - "code, test, deploy" - "sweep back hundreds of thousand of records" - "check the data for selected records, apply common sense to figure out the ones that are wrong" - "come up with a new branch to the business logic" - "come up with the business rule" - and all the cycle all over again.

Guess now why waterfall did not work? After the initial cycle (this is when the project was supposed to get completed, according to the 7-page MS Project plan), the project was considered a failure and the team decided to work overtime to make it up. Guess what? After three cycles, the team was exhausted, business stakeholders frustrated, the project manager left the company, and more resources were thrown in to save it.  After three more iterations, accuracy of data increased but it was still not 100% and the resources started leaving the project - moving on to other projects. It was obvious that 100% was not possible with the complexity of data and the business model which supported flexibility of the new business model.

"Agile!" - you will say - and you will be right. As the team moved to Agile, flexibility no longer worked against us. With each iteration, we increased accuracy of data. Demos provided visibility to the business of the complexities and the incremental progress. The 100% dedicated team were able to show results and it no longer felt like a never ending journey. There were realistic goals set up to achieve the accuracy of data, agreed upon with the business, and the scope was split into measurable chunks that were delivered one by one within a matter of three months.

The step from waterfall to scrum was complete and the original scope was delivered, however, this was not the end of the journey. This was a living system in maintenance mode. New requests continued to come in, and our sprint planning was becoming hectic. Sometimes, we would not have enough tickets to estimate during our planning session, but with the high volume of incoming requests, the end of sprint became a struggle of business stakeholders: who will get in their ticket first? Kanhan "first come-first served" approach did not work as the priority of requests ranged from a business analyst researched options to company's senior management who needed this data to make decisions on running the business. The team was pulled in different directions, and sprint review sessions were surfacing misunderstanding and misalignment. Cadence was no longer there, but the spirit still stayed. And jointly we came up with a solution - scrumban!

More in Part II.

Agile Ethics

Agile started as a discussion of lightweight software development methods. At least, this is why in February 2001, 17 software developers met at the Snowbird, Utah resort. When I talk to people about what attracts them to Agile, I frequently hear that simplicity of approach resonates with them. Remove unnecessary complexities and waste, and do whatever is meaningful and productive, in a way that works now and here. That is beautiful.

This is not what attracted me to Agile as a concept though. I was fascinated by a simple fact that those people were talking about efficient ways of writing code, and yet they started with values. This did resonate with me. Developing machine code and thinking values – as counter intuitive as it may seem and as organic as it can possibly be.

I have been thinking about the value of having values recently. Specifically,  starting last week. I am trying to comprehend the concept of “prioritizing values”. How can you prioritize values? It’s either a value and then it is a priority, or it’s not, and then, there is no need to prioritize anything. Have you heard of work/life balance?  “I have my values but I am doing whatever is best for my family.” Does it mean I can lie or I can betray someone’s trust if I think this is best for my family? This puzzles me and yet, as a Coach, I hear it sometimes.

Throughout years, I’ve learned to understand the concept of “work/life” balance and yet I do not get it. When I am talking to my colleague or helping my son do his homework, am I a different person? Do I divide “me-at work” and “me-at home”? Do I have different values depending on where I am and what I do? Do I feel happy in a different way when my code finally compiled, or when an employee got a chance he has been waiting for, or when my son does subtraction without counting physical objects? Am I working when I write my Agile blog at 2 am in the morning or am I actually relaxing because I enjoy doing it? I think that the concept of “work/life” is made up by unhappy people who think that when work ends, life starts. Luckily, not so for many of us.

Going back to ethics. When I was a child, ethics for me was no different than etiquette. I associated ethics with eating with the right fork and it seemed to me just another unnecessary constraint humans establish to add unnecessary complexity to their lives. As a child, I implemented a lightweight process of eating everything with a spoon. Worked for me.

When I learned that ethics is a set of moral principles, the concept seemed even duller. Until a week ago when I finally understood why Agile is more than a framework for me. What resonates with me that these 17 people in Utah came up with the principles based on their beliefs. They did not think in terms of “work/life balance” or “I hate to do this to my team but I have to do whatever is best for my family”, they thought about what matters most and based their principles on the values they believe in. This is what ethics is for me. It’s our beliefs in what is right and what is wrong. And right for my team and right for my family are not in conflict. Just because there is one right, and it is the choice that I make.

 I believe that it is not material that the product of this Utah gathering was the Agile framework of software development. If this group of people were in aviation, they would envision an amazing plane which will fly faster than any other comparable plane. If it were an economics theory, it would explain many processes in the modern world that we are still trying to comprehend.

No matter what the area of knowledge is – right values create meaningful things, and this is what Agile is for me. Meaningful approach based on firm beliefs in right or wrong that resonate with me. And I find it hard to believe in “what is best for my family” concept because our values do not change when we come home from work. Otherwise Utah gathering would never happen.