Great post from Diana Weber on how the executives at Valpak work (thank you Valpak for being so open!) http://ow.ly/VLcN2
Advertisements
Category / Uncategorized
Agile Reading List
Since 2011, I’ve published a software development-focused reading list. These are books, that in my opinion, should be read by people directly involved in delivering enterprise software, which is my primary perspective. I have refreshed it every few years, and it’s again due for an update. However, I’m doing something different this year, which is to break the list out into some specific recommendations based on a persons skill or role on an agile team. Perhaps you focus your time on writing code – you are going to have a different base of knowledge than someone who is in the role of Product Owner. This isn’t to say that there is not value in reading any book on the list – I do believe there is value in reading about others perspectives – but I wanted to segregate because there are some “must reads” for some roles. Finally, this list really is aimed at those who are trying to learn (or refresh themselves) about agile. If you are an experienced agilist, it’s likely you’ve read a good portion of these books. So without further ado:
Anyone involved with Agile software delivery
Doesn’t matter your role – if you are directly involved in Agile software delivery, these are must reads.
- The Official Scrum Guide
- Succeeding with Agile
- Scrum Shortcuts Without Cutting Corners (if you are already doing Scrum)
Developers
User Experience
These recommendations come highly from a few people directly involved in delivering user experience-focused products using Scrum. They are not mine directly, but I trust the opinion of those who recommended them.
- The Design of Everyday Things
- Lean UX: Applying Lean Principles to Improve User Experience
- Don’t Make Me Think, Revisited: A Common Sense Approach to Web Usability
- Talking to Humans: Success starts with understanding your customers
Testers / Analysts
Is your focus on the team about delivering a product but you aren’t writing code? Are you focused on working with your product owner to envision a solution, groom a backlog, do exploratory testing, and release a quality product? These are for you.
DevOps/IT
Have to worry about your Agile development team shipping software all the time? Get in sync with these two classics.
Product Owners
- Agile Product Management with Scrum
- Principles of Product Development Flow (I will admit that this is not an easy read, but there is key information in here about economic decision making that product owners should understand.)
Executives/Organizational Leaders
- Adaptive Leadership: Accelerating Enterprise Agility
- Lean Enterprise
- The Phoenix Project
- Scrum: The Art of Doing Twice the Work in Half the Time
Agile Coaches/Scrum Masters
I actually think people in these roles, especially a coaching role, should read every single book on this entire list, so they understand the principles and thinking around all roles.
- Agile Retrospectives
- Liftoff
- Coaching Agile Teams
- Agile Estimating and Planning
- User Stories Applied
- User Story Mapping
- Scrumban
- Kanban
Miscellaneous
Here are a few other random recommendations not directly related to agile, but come extremely highly recommended from those whose opinions I trust.
- Team of Teams
- Collaboration Explained
- Training From the Back of the Room!: 65 Ways to Step Aside and Let Them Learn
I’m sure there are many books that are very worthy of being on this list. Our industry is blessed with talented and passionate people who have great ideas to share through the written word.
What are some books you’ve read and would recommend to others? Comment below!
Agility and Fear of Failure
We’ve likely all heard the famous line from Gene Kranz of NASA: “Failure is not an option” with respect to the Apollo 13 space mission, right? Well, most of us aren’t in a position where we are needing to navigate 3 people in a tiny, crippled craft back to Earth from the moon. Many of us are writing business software. Totally different challenge.
In an agile mindset, failure is an option. In fact, we should embrace the fact that we will fail…and when we fail, we want to fail fast.
However, it is human nature to fear failure. We all fear failure, both in our professional and personal lives. I know I do. What it is important to work towards, especially when working within the boundaries of Scrum, is learning that without failure you remain stagnant and possibly regress. Without taking risks or pushing yourself and the team to try something new and different, you aren’t getting better, and you aren’t being truly agile. After all, true agility is, at its core, about continuing to change and refine the way we work to improve it on all fronts – and this means taking risks on occasion to experiment with new ways of working. If we let the fear of failure keep us from taking risks to improve, we are missing out on what agile can bring to us and our customers.
The value of small user stories
There are a lot of good reasons to try to break down user stories into smaller ones (think INVEST model!), but here is one really compelling one: the smaller your stories are, the more likely you are to complete them! Here’s an example on how to think about it:
Let’s say your team looks at the backlog and says they can complete 5 stories in a given sprint. Let’s say those 5 stories are somewhat large. We’ll visualize the stories like this:
The sprint starts, and let’s say disaster strikes and we are only able to complete half of every story.* At the end of our sprint, our stories might look like this (with green indicating completed work):
At the end of our sprint, we delivered exactly no value – zero completed stories.
But what if we broke all these stories in half? We’ll start with this:
Same amount of work to be done, but we’ve spilt our stories out a bit more to a finer grain of detail.
Let’s say we have the same situation – a sprint starts, then disaster strikes, and we only finish half our work. Our stories might look like this:
In this scenario, we finished the exact same amount of work, but were able to get 5 of our stories to completely done – we actually added value.
*Granted, this example is slightly contrived – completing stories also largely depends on how many stories you get in progress at any given time – which should be a small number – but the point remains – smaller stories let you get to “done” quicker, and ensure that a sprint delivers value.
Broad range spectrum
One of the interesting parts about working in the software development industry is the simply massive range of tools, technologies, frameworks, components, etc that are available to do our jobs. I did a quick survey, and at this given moment in time, we here at AgileThought have dozens of different items being used to deliver client service. Here is a sampling – again, this is point in time snapshot – this is constantly changing, and in no particular order…(and I’m likely missing some too!)
- .NET/C#
- Visual Studio 2013
- Java
- Spring
- Eclipse
- Team Foundation Server 2013
- Team Foundation Server 2013 Release Management
- Specflow
- xUnit
- backbone.js
- qUnit
- ASP.NET MVC 5
- SQL Server 2014
- WS-Federation
- Kendo
- Windows Communication Foundation
- AngularJS
- SQL Server 2012 (including Analysis Services, Integration Services, Reporting Services)
- SharePoint 2013
- Entity Framework 6
- Telerik components
- Gradle
- MySQL
- Microsoft Azure (many different components both IaaS and PaaS)
- Windows Service Bus
- WebAPI
- Foundation.js
- Lineman.js
- JSON.Net
- StructureMap
- AutoMapper
- SlowCheetah
- SeriLog
- MSTest
- NSubstitute
- Xamarin.IOS
- Xamarin.Android
- Xamarin.Forms
- MVVMLight
- Sitefinity
- Sitecore
- Invision
- Commerce Server
- Knockout
- Maven
- Swing
- JBoss
- Apache
- Grunt
- Jasmine
- Oracle
- jQuery
- PHP
- Moq
What we do and don’t know about software development estimation
I am personally involved with software development estimation on almost a daily basis. It’s a huge challenge that me and my team face. We give the best possible expert opinion we can, and we often work with limited and fluctuating information. We’ve learned a lot about estimating well, and we have a repeatable framework and guidelines established (which at their core rely on expert opinion).
Given my experiences with software estimation, I believe that if you are involved with estimating software development projects, then you should read this new article from IEEE. It very clearly and succinctly discusses the challenges and what we can do about them with respect to software estimation. The bottom line is: it’s hard and we as an industry still aren’t great at it. But we know what things we can do to make it better and we are working to continually improve.
http://ieeexplore.ieee.org/xpl/articleDetails.jsp?reload=true&arnumber=6774376
If you aren’t doing some of the things that the article discusses, start doing them. If you need help understanding these things – reach out to me – find me on Twitter or LinkedIn – I’d be happy to talk with you!
Agile Open Florida 2014
The reviews are in – Agile Open Florida 2014 was a huge success!
I wanted to share my opening remarks that I made as we got started. I’m sharing these because I firmly believe in what I said, and wanted to repeat myself.
Welcome to the first ever Agile Open Florida! This is the first event of its kind in the state of Florida! I would like to begin by saying that I’m am thrilled to see so many people here today. If you are here today, it is because you value uncovering better ways of developing software, and want to help others do it. You are here because you value individuals and interactions. You value collaboration. You value continuous improvement. And you value community. Our industry is special. Software is everywhere. It runs our transportation, our commerce, our health care. Nearly everything we touch today has software in it. We, as professionals involved with software development, have a duty to make our profession better. To deliver better software. To even, dare I say, make developing software a fun and enjoyable process for all those involved!
I hope that is why you are here today. To get better. To improve. To teach and lead, and to learn. The Open Space Technology format we will be participating in today has been created for exactly that purpose. I encourage you to participate and engage. Our theme today is The Agile Revolution. A revolution cannot occur without passionate individuals who believe in something better. Today we will uncover better ways of developing software. Welcome again to Agile Open Florida 2014!
I also wanted to share some of the feedback that truly made me proud of the event and of all the people that helped make it happen. These quotes are from either Twitter or meetup.com.
Great to spend a day with people who say “we can”
Love the collaboration and willingness to be open!
Wonderful agile community here in FLA!
An absolutely fantastic experience. Getting to meet folks from around Central Florida, and how they’re coming together to make a difference in their organizations by sharing their knowledge, and experiences.
enjoyed meeting so many great people. Your passion to learn and share your agile knowledge is truly uplifting.
I drove all way from Miami and it was 100% worth it! So many Agile passionate and devoted professionals, plenty of ideas, suggestions and tips for our Agile journey. Unique opportunity to learn from and educate peers.
I loved the event and am looking forward to the next Agile Open Florida.
Inspiring and confirming! Thanks so much for organizing. I am in on the volunteer team to take this further!
Aaaaaaamazing
Great day. Learned so much. Everyone very helpful and open. Looking forward to the next Agile Open Florida.
And special thanks to Ainsley Nies who was our facilitator for the day. I had the privilege of spending a little time with her the evening before the event. She’s a fantastic lady and we were extremely lucky to have her with us!
