Just a little respect – It’s about Being Agile

Everyday we get up, get ready, ride our car/public transportation, go to work, to matter, to make someone’s day and after a hard day return home. At every single step there are  various elements that are a part of our life and interaction. One very important one – Humans.

Be it family, friends, co-workers, travelers on the road/public transport – Humans. Yeah, different race, religion etc. – but humans. Every one of us is unique.

We all are marching together to accomplish something – To work. That work – believe it or NOT, affects humans – mostly in a positive way. We as a community are engaged in solving problems for each other, trying to make this journey called life a little simpler. So, if I am supposed to work on something that benefits others, I would myself like to be in a positive frame of mind. When I am feeling good, I have seen it influence positive vibe with others whom I interact.

I am not here to lecture on world peace. Most of the people reading this article and blog, I assume, are adults. Some leaders, agile enthusiasts and great human beings. I just wanted to share a simple message – before we honk at someone, before we shout at a colleague, team member or anyone, before cutting in the line while driving, before showing that finger because someone is not driving the way WE want them to drive – let’s take a moment: breathe, think and then react.

AgileScout blog is not just about agile, but it is about that scout in everyone of us. I’ve been one. I always will be. As a scout, I was taught to respect people and I always will. How about you?

Munch over this thought, while I cook something else for us.


[#Giveaway #Winner] – A Guide to Execution

Giveaway Winner Alert!

We had many tweet it and a couple post.

Here is our random winner!


Send us an email @ info@agilescout.com with address so I can ship out your book!


See Our Past Giveaways:

Help us give away more awesome free stuff to our community and readers! [Become a Sponsor]

Becoming a Certified Scrum Trainer – CST

[I was recently asked what my journey to become a CST was like. So like an Agile blogger, I told them to wait for it to post on AgileScout.com 🙂 ]

The path to becoming a Certified Scrum Trainer (CST) is one of the most arduous yet rewarding experiences I have ever gone through (and I spent 7 years in Master’s programs!). It has not only stretched me, but brought about a greater understanding of “mastery” of a craft, that, no matter how good you ‘think’ you become at something, you can always improve, become better, learn more, and grow as a person.

The day you stop learning is day you become ineffective in your work.

My CST Journey

I began my journey to becoming a Certified Scrum Trainer back in early 2009 when I began my investigation into the process and started collaborating with other CST’s about co-training opportunities. This was a time when the CST application process was evolving (and still is) and the requirements and application process wasn’t fully fleshed out. I, at the time, had been in my 8th year as an independent Enterprise Agile Coach and felt like the CST was the right way to go. I had completed my Certified ScrumMaster designation and my Certified Scrum Professional designation previously.

In early 2009 I had my first co-training opportunity with a fellow Agile coach. They went very well. I was stoked. I was excited. I had gotten a great review and was given priceless advice on how to become better. I felt like the CST was fast becoming a reality. I flew out to meet my 2nd co-trainer and we trained together. Another great workshop. I felt great… Then:

  • Client work picked up.
  • Timing just wasn’t working out.
  • Work-life balance just wasn’t what it used to be.

A full year later, I still had yet to co-train with other coaches and trainers. My client list was full, my schedule was so tight that it became apparent to me that I may not be able to finish this race due to scheduling conflicts and overall timing not to mention funding from the CFO of my house (wife). I was burnt out, tired, and a bit frustrated.

It was all about the timing. It just didn’t seem to work. So what did I do? I made the tough choice to lighten my client load (OUCH! SCARY!) so I could open up opportunities to co-train. I made the time available, I reached out to friends and fellow Agile coaches for time slots, and I invited Agile coaches to come train with me at my client sites. I patiently prayed that the opportunities would come… and they did.

After a full 3.5 years I completed it… The road to becoming an official CST was complete… but the journey forward has just begun. YES!

[Peter Saddington Training on ScrumMaster Roles]

On Co-Training Continue reading “Becoming a Certified Scrum Trainer – CST”

Why Indie Software Developers Need to Embrace Agile

[Guest Post] – Jimmy Wentz is a budding freelance tech writer, gadget and gaming enthusiast, and social media junkie. He writes regularly about O2 and the latest news in the tech, gaming, and social media world.

The Agile approach to development is a series of processes that enables software developers to complete a variety of tasks, or to simply do them more efficiently. People come around to the Agile way of thinking because it’s a process that allows for rapid release, for better and more immediate ROI, and for a larger user base when completed. So why should indies consider Agile?

Working Examples of Software Potential

There are a lot of paid alpha and beta approaches that indie developers often use to make sure they can get crowd-sourced feedback, but also that there’s money on the table during the development process – and not just at the end of it. Guidance – taken with a pinch of salt – from users during development minimises the risk of surprise disappointment upon release. Agile focuses on collaboration with customers, and this is an ideal model of how that approach can be implemented into the development process.

This ties in neatly to the Agile approach, and if anything proves that the model works. Taking a look at the Agile creed, producing working software for someone over simply handing them a written description and mock-ups is a powerful tool when it comes to gaining investment and demonstrating potential. Indie developers often have potential in their ideas and prototypes, and a working concept that can be played with gives a better idea of that potential – mock-ups can be faked or overly ambitious, after all.

Greater Flexibility

Development schedules are the bane of some developers’ existences. It’s not that they’re not useful, but some of them are so rigid that the developer is doomed to be unable to adapt to anything going wrong or any major changes to the software.

As an indie developer, things are going to fluctuate all the time – you’re probably a sole individual or a small team, and while you need to be even more organized than you would in a large company, it also means that roles can switch and shift rapidly with a minimum of disruption.

Agile embraces this approach. While there is an overall goal – the delivery date – everything else is fluid, and there are less hindrances as a result. This is vital, if you’re a small team and don’t have a secondary team to deal with any obstructions.

Keeping Your Spirits High

Working as an independent developer is going to be hard on you, both as an individual or as a member of a team. Working independently carries with it a high level of risk, and with that, pressure. Some developers put their financial stability, careers and sanity on the line for a chance to release successful software.

Agile focuses on maintaining developer morale. It’s about working smarter, not harder – about building a business model that can be sustained, that becomes more profitable over time. Minimizing risk and bringing more structure to a business is going to make developers feel more secure, and happier as a result.

Final Thoughts

If you’re considering the Agile approach as an indie, you could do no better. It’s a system designed to work well for any software developer, and the above examples show how adaptable the processes within Agile development are – always suitable to your set-up and personal methods. Do better – use Agile.


Wearing the Pink*

October is Breast Cancer Awareness Month

Just said goodbye to Heidi.

Welcome back to Meg.

Keeping watch with Alison.

Learned Taekwondo with Joyce.

Laughing with my FBFF Charlene.


Putting friends’ names to a statistic is to honor their battle, their strength.

Many are in this fight, either as practicioner or patient or family or friend or colleague at work.

All should be applauded as we defeat this disease once and for all.


*Football players wear pink shoes in support of Breast Cancer Awareness Month

An Hypothesis is Really a Prototype [Series 4/5]

Agile as the Innovator

Thought bytes

Don’t think research is a phase, it is really ongoing. Prototyping is the way you learn. You learn so much by watching how people learn. It’s OK if the prototype is really rough.

Rapid prototyping your guesses* is an iterative process. You learn just enough to feed into building a better prototype. Then you go out and learn more, build again.

Launching is validating how much more solving is needed. If not solving the problem, re-calibrate.

Service design seems similar to product design – but it is harder to prototype an “experience.”

Product design creates an experience. ID the real issues.

Key is have a clear objective of what you are trying to find out.

Think about the smallest thing you need to do to get the most learning – throughout the entire life-cycle.

Storyboards! Stories describe a type of interaction.

Always design for people.


* My note:  a simple word for hypothesis?


Next up:   Outside in Perspective


Are You Making These ScrumMaster Mistakes?

Scrum asks for a cultural change.  The traditional management style doesn’t work well in a Scrum Team. Scrum calls for servant leadership instead of command and control.

Some Scrum Masters stick to their servant leader role. Especially when the goings get tough, they tend to go back on what they know best – traditional management. Knowingly, or unknowingly, Scrum Masters keep falling into this trap. They start to behave more as project managers than as Scrum Masters.

Several symptoms indicate that the Scrum  Master is struggling to let the Team self-organize.

  • Scrum Master – the task master
  • Scrum Master – the decision Maker
  • Scrum Master – the communication barrier

Scrum Master – the task master  Continue reading “Are You Making These ScrumMaster Mistakes?”