Sunday, April 26, 2015

Bored from a routine daily standup? let the wheel decide.

Wheel Decide is a tool that can be used to when you have a few choices that you need to decide between. The site lets you enter in your own choices and then will show you a wheel with your choices that you can spin and it will give a random answer. This can be used for decisions of any choices that you might need to be decided randomly.  You can also customize with your own questions!

Friday, April 24, 2015

Tribes are more powerful than teams, companies, or even CEOs ...

Every organization is a tribe, or if it’s large enough, a network of tribes—groups of people in which everyone knows everyone else, or at least knows of everyone else. Tribes are more powerful than teams, companies, or even CEOs.  Tribal Leadership show leaders how to assess their organization’s tribal culture on a scale from one to five and then implement specific tools to elevate the stage to the next.

Why scaling agile will fail at your organization?

Many frameworks have been developed to help us implement agile methodology at scale yet; plenty of big businesses are failing to do so. What makes larger organizations more subject to failure in this department? Why? And what can we do about it?

Thursday, April 23, 2015

“How do we measure the success of agile?”

The success of an organization, in terms of survival, prosperity and leadership, increasingly depends on their ‘agility. How do we know then , that our agile initiative is a success? What outcomes an organization would like to see when they go Agile? How well are we doing agile? How do we measure the success of agile?

Wednesday, April 22, 2015

Quick compare of agile tools – evaluating agile tools

Choosing a product based on how it serves your needs and taking cost into consideration. The market for agile project management tools is now mature and saturated, with dozens of offerings from both small and large vendors, and more products hitting the market regularly. What one should do to review a few dozens of tools on the market?
Tools usually will do better in some aspects and stay behind in others. This is natural effect of different influences and experience their creators have. So here’s comparative collection of agile tools, some checklists, prices and specific comparative aspects. 

Saturday, April 11, 2015

Hiring a scrum master? Here's some tips, questions and insights.

What does a successful scrum master look like?

What defines a successful Scrum Master? What are the activities that a successful scrum master do? What are the signs that we are successful as scrum masters and how can we measure this? Here's a collection of points from experts thought around the web. 

Friday, April 10, 2015

Great Agile talks collection

Thursday, April 9, 2015

If you want to teach a Scrum team how to deliver small chunks of working software, have a hackathon.

What is it about hackathons that makes delivering working software in a short period of time possible? Why is it so much more effective than all the formal coaching and training that are aimed to provide developers with the same set of skills for accomplishing the same goal?
Simple: a hackathon is a powerful tool to demonstrate first-hand production of a small chunk of working software. Why? Because it holds the proper psychological aspects that leads developers to perform all those tips and tricks for producing fast working software's without constraints, combined with a lot of fun and motivation and without anyone telling them to use this practice or another.

Most of the times when, as an agile coach, we are engaged in Agile / Lean implementation inside an organization we, usually hear developers or team leaders, say that it's impossible to divide a big user story into smaller ones ! It’s that common and well, that natural to think this way when you are just starting to adopt an agile mindset. "It’s impossible" they say "how can we even think of such an impossible thing?"
The resistance can be very strong, and as a coach you know that you have to face these issues and you need to get those developers from the theory the practice as fast as you can.  We all know that learning how to split big chunks of work takes time, it's not an easy thing to learn or to get used to. There are a lot of sides to this division and a few solutions are typically suggested.

The absence of this skill, the mindset or the understanding of the value in splitting big chunks of work into smaller working chunks can come in many shapes and colors, some of which I have previously detailed here. There are also plenty of ways to deal with this issue. But sometimes it’s not enough, or sometimes after we dealt too much with the theoretical side we might find it difficult to get practical, to ’walk the walk’ when it comes to actual doing.

Here's where the hackathon can come to our rescue. Although hackathons were not originally conceived in order to deal with these types of issues, having participated in several hackathons myself led me to realize that a hackathon is not only a powerful tool for innovation, it's also an amazing way to demonstrate the point of producing working software in a relatively short period of time, using all the tips and trick we aim to teach Agile teams anyway, such as: peer programing, direct and frequent communication, reviewing small chunks of code, working demos, and of course the ability to divide the work into testable working chunks.  These tools become relevant simply because if you fail to use them, you will not be able to produce working software in 24 hours and be ready for a good pitch.
But first, what is a hackathon?

A hackathon is an event, typically lasting between 24 hours to few days, in which programmers and others collaborate intensively on a software project to create a piece of working software in a relatively short period of time. (Wikipedia)

To put it simply, it's an amazingly innovative short period of time, in which people volunteer to do what they like to do (which in our case is coding). During this time, you decide on a project you would like to do, choose your team, collaborate intensively (’hack-eat-sleep’) in order to be able to demo a working product by the time the hackathon’s deadline is reached.


It’s because a hackathon, intentionally or not (probably not), holds a lot of psychological aspects that lets individuals overcome the organization’s control and pressure over producing working software. It releases us of our commitments and sets innovation free in a way that makes anything look possible. You don’t have to develop these things out of someone else’s backlog.

The "when you don’t think of what the other needs for a minute" factor: No one will tell you what to do, or how to do it, and you don’t care about them anyway. You are your own boss, doing the things you want and love to code.

You don’t need to start estimating, or sizing up your tasks.
You don’t have to follow someone else's ideas, your job security is not dependent on your success, or more importantly your failure in this task, your boss is not part of it and has nothing to do or say for or against it -- and whether it will work or not is entirely up to you.  And the best thing is, you pick the idea that you have a passion for, and you are all full of motivation to do what you love (code) and turn your idea into a reality in your own pace.
The pressure of 24 hours, or any other short and near deadline acts as a catalyst to find the right techniques to make it happen.
The prize? Well, it does play a significant role (something that I have a lot to say about, but I’ll leave that to another time). However, I think that it is less significant compared to the inner motivation and pleasure a developer gets out of it.

This autonomy to decide, fail, be your own boss (with a dead line and a prize) can easily drive developers to the obvious solutions which we have been trying to teach them to adopt as everyday practices all along: divide, develop, test, demo.

These techniques were initially developed from this exact line of thinking – by people who hacked their way, enjoyed what they were doing and were under pressure to produce something that works in a short period of time (for whatever reason). They simply came to realize that these practices are a hell of a tool to achieve this.

The “There’s nothing like hands on experience to feel how it’s like” factor:  you can never know how something will work if you don’t try it yourself, and you can never get that feel  for it from mere theoretical discussions.

These are the techniques that have proven to be productive in the past, which we are trying to teach in an environment that does not or cannot immediately acknowledge their value (in different degrees of acceptance). An environment where these techniques were never or almost never tried (or failed due to lack of skill), or were never sold to them in a convincing way or that encounter actual resistance.  You need to convince an organization that it will see ROI without actually having them experience it, i.e., convince it on theoretical grounds. It is subject to criticism and the discussion becomes theoretical. In these situations, when we are trying to teach these skills to an organization, it’s easy to lose the natural environment that motivated them to look into the matter in the first place. Even when we do get a chance to implement the skills in practice, it’s under the pressure of the need to deliver business value, product constraints, budget issues, time limitations and more. 

It will be much easier to try using these skills in a safe and welcoming environment like a hackathon. Sometimes, trying something in its right context brings powerful learning insights which will allow the individuals who experience them to apply these insights in other contexts, which might be more complex or harder to understand at the beginning. The person who experienced it felt how it is and how it should be, so they can move on from there to scenarios where it would have been less likely to happen if they hadn’t practiced it before.

Just try having a hackathon: it will do the convincing on its own. The rest will be easier.  Somehow when developers are part of a hackathon, suddenly they do manage to produce working, quality software in 24 hours. They manage to demo it and they manage to win. They also gain insights regarding techniques they suddenly realized they had used, all the practices that they were probably dead against earlier: peer programing (“As a team leader I’m telling you it’s a waste of our time”), small code reviews ( “I don't believe in that”), demo at the end of each sprint  (“Impossible”). We just need to help them connect the dots and show them that what they actually used was "small chunks", MPV, small code reviews, peer programing, early feedback and more… and it was possible. That’s all there is to it.

 The “fun (theoretical)” part:
Sometimes, people simply don’t want to do what you want or need them to do. but they will perform greatly on things they want to do even, if the two are one and the same.
Then what?
Everyone wants to have fun. During a hackathon, fun is a big deal. This does not mean that we should make a joke of it or bring clowns. Fun is sometimes as simple as enjoying what you do. Artists and athletes do great things since they enjoy them. And they are not the only ones. Children enjoy drawing, playing. Developers enjoy developing, they can spend hours doing it if it’s interesting enough. Hacking for their own idea is enjoyable, and will lead them to use all of those wonderful techniques that will encourage them to get it done well and produce a working product. A hackathon is a great stage for this mindset.

"Full engagement in any pursuit that is meaningful to the individual may not sound like a prescription for fun. But it is, because it tends to lead to what is called flow: a sense of focusing so fully that we lose sense of time, discomfort, even self. Artists and athletes aren’t the only ones who experience flow, children easily merge into this state. A child may experience flow while engaging in make-believe, drawing, swinging on a backyard swing, playing the guitar, fixing a bicycle, even organizing a shelf…"

The “It’s all about bringing the right mindset“ factor

If this exists in your organizational culture naturally you are lucky. Most companies don’t have it. If you don’t have it you can create it. Have a hackathon, let people feel a sense of creation and on the way get them to realize the value of good practices, and why they actually work.

Either way, even if you do try to hold a hackathon it won’t work if the mindset is not there.
I did see few hackathons fail just because the organization managed to ruin it all. Statements like “we are having a hackathon this weekend to close all leftover customer bugs”, or “in this hackathon you need to pick up ideas from the product backlog” or “my team will not be part of the hackathon since they didn’t manage to finish the sprint backlog on time” or “there are urgent issues form customers, you can go back to the hackathon when you’re done dealing with them.”

If these statements represent your organization’s mindset, it’s more than likely that you will never be able to create the right culture for delivering small chunks of working software anyway.

Pics : from @Sisense Hackathon 2014

Things developers say about hackathons that I have collected during several hackathons(Retrospective hackathon quotes:):

·         We realized in such a short time what we need to  do and managed to produce something that works.
·         The time flew by so fast. I never felt the end of the day come so fast until now.
·         It was sooo much fun, connecting with people , working together
·         It made me love what I did
·         Finally , I have the freedom to work on what I have always wanted. It’s frightening too, since I need to prove I can do it. This raises my adrenaline through the roof.
·         Everyone was helping everyone
·         Working alongside Joe I realized that we were constantly developing together, and it was fast, fun and very productive
·         I learned a lot from what Joe and Max were doing, thinking and planning.
·         There were no context switches, we managed to start and finish something in 24 hours. And we even had time to take brakes.
·         It felt very creative
·         We managed to use our own minds to discover better solutions and we didn’t have to get anyone’s approval.
·         When you choose to do something, it’s completely yours.. it was not handed to me by anybody else. It was mine, therefore I could make sure it will be delivered.
·         I could see different thinking patterns other than my own implemented, changed and changed again. We actually built something using 3 different minds.
·         We thought about our idea a few days earlier and we were busy thinking about it… so when we finally started coding we could test our assumptions. We even changed them to better fit what reality showed us to be a better solution for what we wanted to achieve.
·         We can actually show something that is DONE
·         I didn’t know what I was doing here in the first place and what I could contribute, until I had an idea and then... time just flew by and we coded and coded until it was done.
·         The fact that we had only 24 hours and didn’t have to stretch the thing out for an entire week was a good for me -- to start and finish something I can show to everyone without getting bored.
·         The results were amazing. To learn that there are so many things we can develop in such a short time, I couldn’t believe it.
·         I loved being part of a team, working closely, really closely – coding together, testing, reviewing the code.
·         Finally a chance to get out of the routine of fixing bugs or maintaining code or coding for someone else.
·         It was better than a company fun day. I felt connected.
·         It was fun

Tuesday, April 7, 2015

We’re All In the Same Boat -Building the "whole team approach".

The whole team approach is when everyone on the project team is held equally responsible for the quality and success of the project. It yields powerful benefits like lowering risk to delivery, improving velocity/cycle time, producing better ideas and reducing defects and other waste. Like other agile practices, though, whole-team approach requires discipline and diligence.

Things that will fail your agile team performance.

The team is at the center of everything when it comes to Agile and Team formation is another huge problem trying to implement Scrum in most organizations. Probably the greatest hurdle in developing productive teams is understanding what components are necessary to create a team and what will ineffective, low performance team will look like. It is also important to understand why and what is causing it to become an ineffective team so we can start working of  "fixing" things.

Sunday, April 5, 2015

Exploring alternatives to backlog estimates?! - #NoEstimates

#NoEstimates is a hashtag for the topic of exploring alternatives to estimates for making decisions in software development. "...We ought not make decisions in software projects based on estimates and that there are better alternatives for both the suppliers of software products (financially and ethically) and their customers (internal and external".
What is the problem with "traditional" estimations?
What is #NoEstimates?
How does it work?