Friday, 26 May 2017

"Control Your Emotions & Be Positive", by Yoshito Hori

Came across a very interesting article about the relation between controling our emotions and leadership.

Some takes of the article (really interesting!):

- TAKE 1 :)

Techniques to control your emotions:

STEP ONE: Jettisoning anger
  • Analyze WHY you are angry.
Thinking rationally automatically switches your brain function from the emotional to the intellectual.
  • Execute an EMOTIONAL “REFRESH.”
Do something to take your mind off your anger. Play basketball, go for a swim, find some friends to chat to.

STEP TWO: Controlling the emotions
  • Try to recognize the emotion you’re feeling.
  • Judge if that emotion is a positive or a negative one.
  • If it’s positive, amplify it. If it’s negative, reduce it.

- TAKE 2:

Carlos Ghosn, the charismatic French-Lebanese head of Nissan, is respected in Japan and worldwide for his rescue of the struggling national carmaker in the late 1990s.
Ghosn bases his approach to public speaking around a simple cast-iron rule: Your audience will forget 90% of what you say within 24 hours. What stays with them is your attitude, your emotion, the feelings you convey.


Here's more:
https://www.linkedin.com/pulse/lesson-leadership-control-your-emotions-positive-yoshito-hori

Have fun! :)

"It’s Effort, Not Complexity", by Mike Cohn, and the relation (?) between Story Point estimation and Time

Mike Cohn establiches a relationship between Story Point estimation and Time, a relation which is not consensual.

He says it better:
"Suppose a team consists of a little kid and a brain surgeon. Their product backlog includes two items: lick 1,000 stamps and perform a simple brain surgery – snip and done. These items are chosen to presumably take the same amount of time. If you disagree, simply adjust the number of stamps in the example. Despite their vastly different complexities, the two items should be given the same number of story points – each is expected to take the same amount of time."

Take a look. It's in here:
https://www.mountaingoatsoftware.com/blog/its-effort-not-complexity#.WR3nW4OtKng.linkedin

Have fun! :)

Thursday, 18 May 2017

"7 Traits of High-Performing [Lean] Teams", by Maja Majewski

I came across an article about High Performing Teams.

Although the article is lean-oriented, I believe these 7 traits are easily applicable to any team with a high performance motivation.

So here's my interpretation of these 7 traits to any team who values High Performance:

1. They Don’t Let Lack of Lean Experience Stop Them

Your team wants to be a High Performance team. So, if you use any methodology that is Agile oriented (it helps :)), if your team is not very experienced with the used methodology shouldn't be a problem, as long as the team WANTS to performe better and better.
Motivation is key!

2. They Have an Executive Champion

It really helps a lot to have your top management with the same mindset. It allows the team to have space for trying and improving in a continuous improvement environment.

3. Their [Lean] Journeys are Unique

Any path to adoption of a high Performance mindset can lead to success, as long as the team is committed.

4. They Have a Dedicated [Lean] Team/Position

Having someone pushing forward and always reminding the team to do better, and how to improve more and ore is a key facto.
In many Agile adoption teams, it is really helpfull to have a good (!) Agile Coach.

5. They Use Power Tools

Make teams use the best tools suitable to each reality. Use them well and they will surely help!
Make the best out of performance measure tools, task oriented tools, etc.

6. They’re Laser-Focused on Flow

Increasing team productivity, make processes more and more efficient, and use the best change management tools available, will surely contribute to improve the frequency of quality delivery.

7. They’re Metrics-Obsessed
"metrics allow teams to paint a holistic picture of their current and past performance, helping them make targeted improvements" - couldn't say better, really :)

Good metrics are very helpful indicators on how we're doing. So, teams should be taking the best out of metrics, in order to improve continuously.



Have fun! :)


"The tragedy of 100% code coverage", by Daniel Lebrero

"It is funny how things turn around. ​ For fifteen years I have been preaching TDD (Test-driven development, or as it used to be called: test-first approach), or at least for developers to write some unit tests. However, in recent times I have found myself saying more often, 'Why did you write that test?' instead of, 'You should write a test.'"
Daniel Lebrero on 18/05/2016

It presents some interesting opinions & views, worth to take a look...



Have fun! :)

Tuesday, 18 April 2017

"User stories are not requirements", by Emal Bariali

Interesting article that deepens the role of the Business Analysts, and makes it go the extra mile!

The takeaways from the article:
  1. Recognize that your output as a BA has huge downstream impacts.
  2. Understand that meeting the needs of your downstream stakeholders (the dev team) are as important as meeting the needs of your upstream stakeholders (the business side).
  3. Learn what it takes to make sure your downstream stakeholders have what they need to build a solid solution.  A little bit of "systems thinking" will take you a long way to help meet the developer needs.
I would sum it up in something like this:
  1. BA work is crucial for downstream 'stakeholders' *
  2. The BA works for up and downstream 'stakeholders'
  3. Do some System Thinking to be sure the requirements are fully understood by downstream 'stakeholders'
* not sure I agree with this term but it works for now...

It's worth to take a look :)

Here's the full article: https://www.linkedin.com/pulse/user-stories-requirements-emal-bariali-mis-csc?trk=mp-reader-card

Have fun! :)



Thursday, 30 March 2017

"The Scrum Guide" - Free eBook :)

Here's a link to the "The Scrum Guide" in the views of Jeff Sutherland and Ken Schwaber:

http://www.scrumguides.org/docs/scrumguide/v2016/2016-Scrum-Guide-US.pdf

It intends to be "The Definitive Guide to Scrum: The Rules of the Game".
Personally, don't agree with it all, but, hey, nothing like having a critical reading perspective, right? ;)

Nice readings & have fun! :)