I wrote a couple of posts back about my ScrumMaster training that I would wrote more about how I would apply this to my job. This is the second such post.
This one is about the need to balance the discipline of what you are doing correctly with the ability to adapt, learn and change. If one is not careful, you might "discipline" as a static thing. In reality, while you are developing and practicing your discipline(s), you are at same time (or you should also be) learning and adapting. When viewed this way, discipline is a much more active endeavor. In his slideshare titled "The Tao of Agile", Fabio Armani states that "Both (Lean and Agile) offer a thinking tool set that allow us create new models and different approaches".
Reflecting on one of my recent projects, I had the thought, "Finally, the Product Owner is starting to 'get it'. It's a good thing I was so disciplined about this!" When I went back to review with them what they had "finally learned", I could also see that my own approach had adapted and evolved. I was also "getting it" and learning things about the project that were not initially clear to me. This is what the an Agile MindSet is all about -- being open to this "thinking tool set". Can you recognize when new models & new approaches either need to happen or in fact have already happened -- either for you customer or yourself?
An Agile Mindset
Monday, September 28, 2015
Friday, September 11, 2015
Some Thoughts on MinneDemo21
Last night I attended MinneDemo21. It was the 1st time I attended after several attempts. I will be attending again, shame on me for not getting there earlier. Several general reactions:
- There *is* cool stuff happening in my local community
- There are lots of energized, passionate individuals working on that cool stuff
- There are few (need to be more) "deep pockets" trying to encourage, nurture, and fund this so more cool stuff will be created locally.
- Shame on me for not being a little fish in this pond or doing more to connect deep pockets with the community.
In the spirit of doing my "little fish" thing to nurture and encourage, here are links to the companies that presented along with my twitter stream that captured my reaction in realtime.
The Presenters:
Want more? Here are videos of each presentation posted to TECHdotMN
IMO @RecordTogether steals the show at #minnedemo
— AnAgileMindset (@AnAgileMindset) September 11, 2015
Thanks to the guys @redriverkitchen - a veggie burger sounds GREAT #minnedemo
— AnAgileMindset (@AnAgileMindset) September 11, 2015
last demo at #minnedemo - RecordTogether collaborative music SW to add other instruments to a track of an instrument that you do play
— AnAgileMindset (@AnAgileMindset) September 11, 2015
Next up at #minnedemo @qonqr - it’s like playing Risk in a real map. I have not been a game player. This may change that.
— AnAgileMindset (@AnAgileMindset) September 11, 2015
Now on stage at #minnedemo @bestbuy - if you work on http://t.co/FuqdyGNudr your code will be running by next Monday #DevOps
— AnAgileMindset (@AnAgileMindset) September 11, 2015
Parsec Labs at #minnedemo - just the 2nd demo tonight that is not a mobile app talking about storage appliance
— AnAgileMindset (@AnAgileMindset) September 11, 2015
Now on stage at #minnedemo 2 employees from @Code42 - they just met on stage - the Noob - “I lost a lot of data in my day”
— AnAgileMindset (@AnAgileMindset) September 11, 2015
Bushel (created by JAMF) is next up at #minnedemo - mobile device management for small businesses
— AnAgileMindset (@AnAgileMindset) September 11, 2015
Next up at #minnedemo Occamscan - another mobile app to help consumers save money on grocery store purchases - “consumer big data”
— AnAgileMindset (@AnAgileMindset) September 11, 2015
Next up at #minnedemo HomeSpotter - streamline the process of looking for a house on a mobile device while collaborating with a realtor.
— AnAgileMindset (@AnAgileMindset) September 11, 2015
The 1st demo at #minnedemo is up - “When I work” Mobile Saas co. - help hourly workers to schedule and track time, swap work shifts
— AnAgileMindset (@AnAgileMindset) September 11, 2015
Sunday, July 5, 2015
Don’t be a Killjoy
If I am dating myself with the title of this post, it was one of the more valuable take homes from my recent CSM Training Class. I had always considered myself to be very flexible and adaptable. However, during one group exercise, I was most definitely a Killjoy. This came during one of our opportunities to learn and adapt — an extremely important agile ability. I justified this (rationalized this) by “suggesting” to the group that we were not yet ready for a change one team-mate was trying to introduce since he had introduced it very late in our short planning period. We went through one more iteration and eventually did adopt this suggested change (it was indeed a breakthrough in the team’s output) with my full support.
However, there were three important things the instructor pointed out this particular exchange:
However, there were three important things the instructor pointed out this particular exchange:
- Don’t be afraid to “Fail Fast” — This was indeed my greatest fear. Given how late in the planning cycle my team-mate had suggested this change, I feared that our output would be even lower that previous iterations. No doubt we would have quickly realized that we did not all know what to do. This this fast failure leads to the second point.
- Don’t be afraid to dynamically adapt — Even during your iterations. I saw numerous times during this and other exercises that team members were constantly giving each other feedback and were adapting their techniques and methods mid-iteration.
- Lastly, how you deliver the message *is*important. When I said that I “suggested” we were not ready, it came across *much* more forcefully than a suggestion. While I know the person that suggested the idea knew I liked it, others on the team might have heard in my language that it “was a terrible idea”. As I mentioned previously it was a good idea that we eventually adopted.
Monday, June 29, 2015
Certified ScrumMaster Training
Despite the fact that I have been a Agile Practitioner for many years and while I sent (read paid for) many employees to attend classes and certification tests over the years, I had never done so myself. A few weeks back I rectified that and attended CSM training/certification from the Scrum Alliance. I went into the class thinking that much of this would be repetitious (parts of it were), that there would be beginners (there were) and that the exercises would be useless (they *weren't*). Each of those points is worth a quick paragraph.
Material
It's never a bad idea to review the assumptions and principles on any material. In this case I found the most valuable was review of the roles of a Scrum team. I was able to apply this to my current projects and realized that in at least one case, I really do not have a Product Owner. One attendee asked, "Without a Product Owner, do you really have a project?" This is an appropriately challenging question. It was somewhat encouraging to hear that I was not alone in this challenge.
Other Attendees
There were several attendees that had recently been laid off and as part of their severance packages included some training dollars. Several of them were classic PMP's from the PMI. They were struggling with the basics of SCRUM since the material was very different from their backgrounds. However, their questions were valuable as they allowed the instructor to underscore key points and assumptions. The experienced Agilists were also add some stories from the front lines that added to the discussion. As with all training that allows you to "get away", the real value is in hearing those real world stories -- what have other people tried and not tried, what has work or not worked, etc.
Exercises
I take my hats off to the Scrum Alliance on the exercises they include in their training. These no doubt have been refined over the years. But given the relatively short time frame of a two day class (you take the certification test on your own after the class) the exercises most definitely gave us a chance to quickly plan, execute, adapt and repeat. It was both fascinating to watch and be a part of. In nearly all of the cases it taught me somethings(s) about myself.
Over the next couple of blog entries, I will share more about what I learned about myself and how I will apply it to my work.
Material
It's never a bad idea to review the assumptions and principles on any material. In this case I found the most valuable was review of the roles of a Scrum team. I was able to apply this to my current projects and realized that in at least one case, I really do not have a Product Owner. One attendee asked, "Without a Product Owner, do you really have a project?" This is an appropriately challenging question. It was somewhat encouraging to hear that I was not alone in this challenge.
Other Attendees
There were several attendees that had recently been laid off and as part of their severance packages included some training dollars. Several of them were classic PMP's from the PMI. They were struggling with the basics of SCRUM since the material was very different from their backgrounds. However, their questions were valuable as they allowed the instructor to underscore key points and assumptions. The experienced Agilists were also add some stories from the front lines that added to the discussion. As with all training that allows you to "get away", the real value is in hearing those real world stories -- what have other people tried and not tried, what has work or not worked, etc.
Exercises
I take my hats off to the Scrum Alliance on the exercises they include in their training. These no doubt have been refined over the years. But given the relatively short time frame of a two day class (you take the certification test on your own after the class) the exercises most definitely gave us a chance to quickly plan, execute, adapt and repeat. It was both fascinating to watch and be a part of. In nearly all of the cases it taught me somethings(s) about myself.
Over the next couple of blog entries, I will share more about what I learned about myself and how I will apply it to my work.
Thursday, July 31, 2014
The Importance of Common Language
I had previously written about “binary clarity” and how gratifying it was to hear others using that language after I left a position where I had used it frequently. The reason this was so gratifying was I realized the others had internalized what it meant. In short, the group had developed common language Further, they had internalized the importance of the concept.
Today, while attending a daily standup (I am now an observer, not an active participant) I heard the use of more common language. When I heard term used, I could tell everyone knew what it meant and what actions would follow.
I have an older brother that is now retired. He frequently comments on how he enjoys having his kids quote him. He likes to add, “Others will carry on after me”. Common language is critical. It’s even more gratifying when you are the originator of the language. It confirms that you have had an impact on the group and that others will “carry on”.
Today, while attending a daily standup (I am now an observer, not an active participant) I heard the use of more common language. When I heard term used, I could tell everyone knew what it meant and what actions would follow.
I have an older brother that is now retired. He frequently comments on how he enjoys having his kids quote him. He likes to add, “Others will carry on after me”. Common language is critical. It’s even more gratifying when you are the originator of the language. It confirms that you have had an impact on the group and that others will “carry on”.
Tuesday, July 15, 2014
Agility, Demos, and Credibility with your Customer
Once I had the opportunity to present at my company's annual User Conference. The Product Manager for the session set a goal that in hindsight was a pretty aggressive demonstration. When he walked through the outline, I thought, "Yep, that can be done" and the synopsis went out to the conference attendees. As frequently happens, work and life got in the way of the preparation time. I was fortunate enough to get some fantastic assistance from my colleagues on the requisite slides and that helped to further focus "the story" that the demonstration. I entered the conference feeling reasonably prepared.
For some reason the day before the presentation, "the buzz" around what I was going to demonstrate began to build. There was a Field Services employee that read the session synopsis and said, "You are going to do *that* during a live demonstration-are you crazy?" Shortly before the presentation, I ran into a customer that had intended to come, but then had another commitment. He apologized by saying that he was going to have to miss my "high wire act". I was suddenly nervous.
For some reason the day before the presentation, "the buzz" around what I was going to demonstrate began to build. There was a Field Services employee that read the session synopsis and said, "You are going to do *that* during a live demonstration-are you crazy?" Shortly before the presentation, I ran into a customer that had intended to come, but then had another commitment. He apologized by saying that he was going to have to miss my "high wire act". I was suddenly nervous.
Wednesday, April 30, 2014
Agile Performance Testing
Two recent events had me thinking about the subject line. One was a Webinar given by CloudBees titled, “ Adding Performance Testing into the Continuous Integration Process “ (the link is the Webex recording), the other was reading a blogpost shared by a colleague, "Combining Agile with Load and Performance Testing: What am I in for?” In essence both of these presentations ask the same basic question -- with all the focus on Continuous Integration and rapid feedback, "Why hasn’t development embraced Performance Testing as part of their development cycles?" The short answer from both — “It’s Hard”
Subscribe to:
Posts (Atom)