Youth in Agile is a new blog series sponsored by SolutionsIQ that gives young Agilists a voice in a world that is constantly changing and asking increasingly more of them. The contributors to this series are college-aged individuals who are part of the SolutionsIQ community — interns, participants of a certification course, family to SolutionsIQ’s core community. As Agile becomes more and more mainstream, it’s imperative that we begin listening to the next generation of Agilists who have hopefully learned from us and our mistakes and can continue down the path of growth in the work place that this generation and previous ones have carefully laid out.
This blog was written by Izzy Quartararo who works in the Finance department of SolutionsIQ.
I started working at SolutionsIQ, when I was 16 years old, processing employee expenses as well as performing a few other small tasks a few hours a week. I was still in high school at the time. When I was 18 and graduated, I decided to go in a new direction and went on to pursue something different for a little over a year. After I felt that I learned all that I could learn, I decided to come back to SolutionsIQ! I was welcomed back with open arms and I am so grateful for that. I have been back for about two years now and SolutionsIQ has changed so much! In a good way, obviously. They have acquired two new companies and nothing could be more amazing to watch. SolutionsIQ is always presenting me with new challenges as a result of these changes, which enables me to gain new and valuable knowledge from all of my experiences here. I am going to school to get my Bachelor’s Degree in Human Resources and it is always great to be able to apply the things that I am learning in school to what I am doing at work. I have learned so much about Agile and it has been so valuable to me, both inside the workplace and out.Agile in the Workplace
Currently I work full time as part of the Expense Team in the Finance Department. The Expense Team processes employee expenses as well as assists the Billing Team with invoicing our clients for the billable expenses that our consultants incur. The Finance Team uses several important Agile activities in our day-to-day work as well as our near-term and long-term strategy. SolutionsIQ’s Finance Team does a standup every Monday, Wednesday and Friday at 11:00 am. Members of the team that aren’t physically in the office call in remotely to participate. Standup gives us a chance to visually see what everyone is working on for the next two days, reach out for help if it is needed and allows the team to connect, especially the ones who work remotely in other parts of the country. When the Finance Team gets together and everyone makes their tasks visible to the rest of the team, it significantly impacts the team in a positive way. Because of the monthly billing cycle, the Finance Team has 30-day sprints ending on the tenth of each month. We also do occasional retrospectives when they are needed, mostly if there is a conflict of some sort. Every time we do a retrospective as a team, I always find them to be very useful and I leave knowing exactly what action items are my responsibility.
A few weeks ago SolutionsIQ’s Expense Team and Billing Team got to participate in a Value Stream Mapping session with our very own consultant, Jeff Nicholls. Our goal for the Value Stream Mapping was to make visible all of the impediments in our process. Even though the members of our team knew exactly what the impediments were beforehand, it was very useful to be able to sit down and make them visible for others that are not included in our everyday processes to see. Both teams left the meeting feeling that positive changes were going to come out of this transparent and collaborative session. Sessions like this make me feel so lucky to be able to work at SolutionsIQ.
Another reason I’m excited to work at SolutionsIQ is that I have been given a great opportunity to transition over to the Consulting Ops Department. As a result of growing so quickly, SolutionsIQ has many, many more clients, which should come as no surprise to the people who have been following our growth. Clients with a large demand require extra effort in monitoring their budgets, organizing their expenses, etc. and that is a large portion of what I am hoping to accomplish! I am looking forward to taking my past Agile experiences into this role, as well as learning a lot more as I go.My CSM Experience
In June I took a Certified ScrumMaster course here in Redmond, taught by SolutionsIQ consultant-trainers Bryan Stallings and Jeff Nicholls. Going into this class I knew that I was going to be familiar with most of the material that would be covered, so I wanted to mainly focus on the idea of “How can I use these Agile strategies to improve my work processes?” As I participated in this two-day class, I took notes that were specifically applicable to me instead of trying to record all the information that was being provided, whereas most of the other students were doing just that. After the class, I left with several sticky notes with action items on them that I was able to work through in my own time. My main focus was on strategizing how to get the consultants to submit their expenses in a timely and accurate manner, for example, submitting them every week, rather than waiting until the end of the month. Overall, the CSM course was a very valuable experience, not only to watch Bryan and Jeff do what they love, but to get new perspectives on Agile and SolutionsIQ as a whole.Agile at Home
Recently I decided to move into my own one-bedroom apartment, as well as take two summer classes. With that came the obvious bills, random and unexpected expenses and all around a lot of craziness. As if that wasn’t enough, I decided it would be cool to get a fish and then later a cat, which if you’re wondering, isn’t the best combination. I very soon began to get overwhelmed and stressed about all the changes in my life. So the other night I decided to use what I learned at work to get organized. I pulled out some sticky notes and put together a Kanban board (“To Do → Doing → Done”) on my dining room wall of my new apartment. The items going on the “To Do” section included bills, chores, assignments and responsibilities. I included deadlines (my version of the time box) for each of these items as well. I then organized each of the items by deadline and placed them on the chart accordingly. Instead of doing the typical two-week sprint recommended in Scrum, I decided that I would do a short, one-day sprint and that I would have a new sprint for each day of the week. After putting together my chart and setting up my five, one-day sprints, I was completely aware of exactly what needed to be done and by when. Being the OCD, overly organized person that I am, I began to feel much more relaxed and ready to tackle the tasks at hand. Had I not worked in an Agile work environment for several years, I might never have thought of approaching my at-home tasks in this way.
Using Agile practices at home can make it easier to complete chores and home projects.
Click To Tweet
At SolutionsIQ, I also have the privilege of working with my amazing step mom, Kelly Quartararo. She works in the Consulting Operations department reviewing contracts and project margins as well as assisting with forecasts. Since we both work in an Agile work environment, a lot of the time we may have similar approaches to things. For example, oftentimes before we go on large family vacations, Kelly will create a large Kanban board on their dining room wall for everything that needs to be packed, made, put together, etc., before we leave for vacation. Also, since our family ratio is 5 kids to 2 adults, it’s always important that everyone is aware of the tasks at hand. The last time we did this on our family camping trip to Daroga State Park in Eastern Washington. What was most memorable about that experience was that my brother Josh couldn’t come and so we printed out a “Flat Josh” version of him that we took everywhere with us, even jetskiing! Because community is important, right?
This visualization of work is a key concept in Agile and works for any team in any workplace. It is a way for everyone to collaborate and accomplish what needs to be done, even if it’s just because the kids love to move the sticky notes from one section to another, which honestly I am guilty of myself. All in all, though, I feel that working at SolutionsIQ is helping me grow into a more collaborative adult with a more Agile way of thinking and being.
Agile Eats is our semi-monthly e-blast chock full of tips and tricks too good not to share. Subscribe now!
The post Youth in Agile, Part 3: Visualizing Tasks at Home and in the Finance Team appeared first on SolutionsIQ.
“It usually takes about 36 months to bring a new TV platform to market but we had a minimally viable product in 8-10 months and brought the full product to market in 18 months. SAFe helped our relatively small team build and run a world-class product and guided us when in doubt, showing us the way toward Agile product development flow.”
—Simon Berg, Agile Program Manager, Swisscom Entertainment Projects
Congratulations to Swisscom for developing an award-winning IPTV product, and for doing it in half the usual time-frame. Swisscom’s SAFe story shows what high levels of collaboration between business and IT can accomplish.
When Swisscom initiated plans to bring a new IPTV offering to the market, they knew they had to find a way to get to MVP ahead their competiton who was building a similar product. Coming from a “PMI-style, waterfall, multi-project environment that was transitioning into a home-grown, scaled Scrum approach,” they ultimately turned to SAFe to scale Agile in earnest. PI Planning meetings were new to Swisscom, and when they saw how the event brought together disparate teams that had never before worked with each other, they understood the power of that event to align those diverse stakeholders in a shared vision.
After a year and a half of incrementally adopting SAFe, the results were impressive:
• Swisscom brought TV 2.0 to market in 18 months, where it would normally take 36 months
• They decreased the time from code-ready to mass rollout from 9-12 months to six weeks or less
• Testing now requires just three people, instead of dozens
• Sales and customer satisfaction scores are strong
Perhaps most telling, the product won an award for “Best multi-screen experience,” an honor not usually bestowed on telecommunications companies. Now PI Planning has become standard practice, and other product units have taken interest in SAFe. It’s kind of cool when you realize that Swisscom took their first steps in technology in 1852 when they set up the Swiss telegraph network. Read their full story here.
Many thanks to Simon Berg, Agile Program Manager, Swisscom Entertainment Projects, for sharing Swisscom’s story.
Agile Estimation is an easy concept to understand, but where the rubber meets the road and legacy artifacts such as LOE (level of effort), utilization reports, and other artifacts come into play and confuse is the issue. Questions like, “should we estimate in hours?” and “how do I convert t-shirt sizes to points?” arise. It’s important for an organization to come to a common way to estimate, especially as we move up the governance model from team to program to portfolio.
There are many studies that show estimations are valid in the short-term and they are undependable in the long-term. Additionally, when reviewing any value stream like a software delivery lifecycle, utilization takes a back seat to throughput.
I’m not going to get into the many types of Agile estimation. I will however provide guidance and a standard used among my colleagues and I at LeadingAgile.Epic Estimation
Epics are coarse grained items that we want to build into our product or process. I prefer Epics fit in a release but they can span releases. Epics should be in the one to three month time frame. T-shirt sizing of Epics would be:
S – 1 Sprint 
M – 2 to 4 Sprints
L – 5 to 6 Sprints
Larger that 6 sprints and the Epic should be broken down
 Sprint or iteration lasting 2 weeksFeature Estimation
Features fit inside a release. We need to plan out a release. To do adequate release planning we feature map. The features are sized and prioritized to determine how they lay out over our sprints. Features should be estimated in weeks, so I suggest a one to five week time frame.
Avoid using points on features. Once user stories are broken down, and story points applied, roll up the story points to the feature level. As a result, this will give you the truest “Feature complete percentage” as the team completes user stories in the feature.
If you have a team that is very experienced and has a lot of referential stories, then using story points at the feature level can be acceptable. If this is the case, I suggest you update the points as the user stories are flushed out.User Story Estimation
User stories should be broken down until they are one to three days in size. New teams may have a difficult time with this, but it should be the goal of the product owner team and the delivery team to work towards this goal.
Consequently, story points should be used to estimate stories.New Agile Teams
As a part of sprint planning, new teams should perform a task breakdown. During sprint planning, each story is broken into tasks to be performed; database update, java interface needs to be updated, update unit level tests, etc. These tasks are assigned in hours.
Each task should be kept under eight hours so we can see a smoother sprint burndown each day. Anything larger doesn’t provide visibility to the team. Teams that are doing task hour breakdown will use an hours sprint burndown. Teams that don’t break their tasks into hours would use a story point sprint burndown. Some tool vendors may only support one version of the burndown per instance of the tool. Therefore this should be investigated prior to determining how the team will manage it’s sprints.Agile Estimation Flow
[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
We've finally implemented keyboard shortcuts into Targetprocess. You can review all the available shortcuts by pressing: "ctrl" + "/" (or, "cmd" + "/" for Macs).
There are currently 3 places in Targetprocess where shortcuts are available: views (Boards, Lists, Timelines, One-by-one views), entity views (the screen that appears when you open a card), and Quick Add popups. You can read more about keyboard shortcuts at this User Guide page.Owner as a lane
We’ve added the possibility to include an Owner lane when setting up a view. This means you can now build views that group entities by the person who created them. Users with admin permissions can easily change the owner using drag and drop. Owners in lanes are filtered by the projects and teams currently selected in the global context.
- Added a view menu search placeholder and a "no results" search message
- Fixed an error that would occur when trying to run a Test plan owned by a deleted project from the Team Iteration view
- Fixed the absence of required custom fields in the project/program context quick add form
- Fixed a problem with incorrect card counts in the Person lane when there are multiple user assignments
Jerry Doucett is now offering consulting in implementing SAFe 4.0, as well as teaching the following courses and workshops:
1) “Leading SAFe 4.0” course for the SAFe Agilist (SA certification)
2) “SAFe Product Manager – Product Owner” workshop (SPMPO certification)
3) “SAFe 4.0 for Teams” course for the SAFe Practitioner (SP certification).
Please reach out to Jerry by email or on LinkedIn if you have any questions about SAFe or about scaling Agility.
The next SAFe class is “Leading SAFe 4.0” on September 08 and 09. Please see WorldMindware.com for more information including registration.
Learn more about our Scrum and Agile training sessions on WorldMindware.comPlease share!
The post Announcement: 4 New Steams of SAFe courses offered appeared first on Agile Advice.
Co-located teams are more effective communicators and can sometimes experience increased productivity by up to 60% if situated together in the same room. More simply stated, the greater the dispersion factor, the greater the challenge of collaboration. Note that time zones are often considered the largest dispersion factor and can have a greater impact than geography.
Although it is strongly recommended that teams be co-located, it is not mandatory to success. In fact, certain Agile practices have factors, tools and techniques inherent to them to help bridge some of the shortcomings of increased dispersion, such as a higher reliance on frequent collaboration and communication. But to be clear, they do not replace the value of face-to-face conversation, they are merely a crutch to not having it. (Senior Agile Coach Jerry Doucett)Learn more about our Scrum and Agile training sessions on WorldMindware.comPlease share!
The post Quotable Quote: The Greater the dispersion, the greater the challenges appeared first on Agile Advice.
Not sure how to get started with continuous improvement? Understanding how to use data to drive improvement efforts...
The next time you’re at an art show or art gallery of any kind, walk up to an artist and ask them to install an electrical outlet in the wall on which their painting is displayed.
After ignoring the inevitable look of bewilderment and snarky response, grab some tools and start hacking the wall apart. Tell the artist that you just need an outlet here so you can recharge your phone.
Be sure to ask them to help.
I’m not 100% certain how this will end, but I can imagine it will involve security guards, police and possibly handcuffs.
As ridiculous as this scenario sounds, though, I feel like this is what I’ve been doing with Docker for the last few months.I wanted to access my app via the container’s IP address.
When using the default “bridge” network, a docker container has it’s own IP address. This can be viewed via the “docker inspect <container name>” command.
That being the case, it would make sense to access the app via that IP address, right?
I thought it made sense, and I expected to be able to use the containers IP address.
So, I dug into the documentation.
I asked on twitter and in various slack communities.
Finally, I asked on the Docker forums. And the response I got?
Basically, a big “nope” and “don’t do that.”
But I wasn’t happy with that answer.
I continued to suggest that it should work this way, even though it doesn’t.
Sure, it may be possible on linux … or with kubernetes… or some other strange mechanism that I’m not aware of, yet.
It took a while to sink in. Eventually, I realized what the real problem was, though.I shouldn’t even be trying to do this.
After a few hours of … “conversation” … with my friend Fred, via the WatchMeCode community slack, I finally started to understand that my expectations of Docker were wrong.
I use a lot of of virtual machines to host services that I don’t want on my laptop directly. Things like Oracle, SQL Server, an LDAP server, etc.
Virtual machines are great at handling these.
Lately, though, I’ve been moving some of these services to Docker. RabbitMQ, MongoDB and my Oracle XE installation are all in Docker containers, for example.
Life is great when I publish the needed ports from the container through my localhost. Everything works peachy.
My experience with virtual machines clouded my Docker expectations, though.
I saw that Docker was technically running on top of a virtual machine, and I immediately went into a virtual machine mentality and expectation set.
But here’s the thing…A Docker container is not a virtual machine.
Yes, it may technically be running on a virtual machine, but that is an implementation detail – hidden behind the scenes – not a feature to be used.
An application hosted in a Docker container is a “virtualized” (containerized) application, not a virtual machine.
Yes, you can find Docker images that include a full linux distribution in them.
These distributions are there to support the application that is contained within, however. They are not to be executed as if they were a full, general purpose virtual machine.This perspective matters, because it sets the expectations for a containerized app.
Imagine for a moment, that you have two node / express apps that both use port 3333.
What happens when you try to run both of them on the same machine?
You get a big fat error, saying the port is already in use.
Now, does it matter that the application is hosted in a Docker container?
Not really – at least, not from the perspective of the host machine when you try to bind port 3333 to more than one container.
You can’t run two apps on the same port of the same IP address. Not with any app on your machine directly, and not with Docker.
And why, you might ask? Because …A Docker container is application virtualization.
And application virtualization is not the same as building a complete virtual machine to run a single service.
A Docker container happens to contain everything that the application needs, to run. But the intent and behavior of that container is to run the application on behalf of your host machine.
It’s a black box that allows you to cleanly separate applications that need different versions of the same dependency.
It gives you the ability to stop and start a server or service as if it were running on your computer directly, without having it installed or configured on your computer.
Docker’s job is to let you sandbox different apps in a system, so they don’t clobber each other’s configuration.A Docker container is art hanging on a wall.
Art occupies a physical space. And due to those pesky laws of physics, one piece of art will prevent another from occupying the same space.
This was the mistake I made in my view of Docker.
I expected each Docker container to be a separate art gallery. In reality, each container is a piece of art hanging on the wall.
I should have been asking the artist about the intent or meaning of their painting, enjoying it for what it is.
Instead, I wanted to know why there wasn’t an outlet in the wall. I wanted the artist to help me with construction work – something that they may know nothing about.
I decided to try and tear up the wall on which the art was mounted, because I thought the wall was a fundamental part of the installation.
And the installation, as I saw it, wasn’t living up to my very inaccurate expectations.Tweet
There must be a consistent commitment and engagement from all parties in the organization towards adopting the Scrum framework, Agile methods, and thinking. The initiative must be an open, collaborative experience and there must be complete understanding and alignment by all parties in assuming the risks and rewards as well as sharing in the effort. This includes not only business partners and their IT counterparts, but their leadership as well as all of the people and teams supporting an Agile initiative. (Senior Agile Coach Jerry Doucett)Learn more about our Scrum and Agile training sessions on WorldMindware.comPlease share!
The post Quotable Quote: Consistent Commitment is Key To Team Success appeared first on Agile Advice.
Brain Rules: 12 Principles for Surviving and Thriving at Work, Home and School by John Medina – A description of rules with how our brain works and how we learn. Our visual senses tend to trump our sense of smell. We need sleep to restore our energy and to help us concentrate. Spaced repetition is important, but assigning meaning to new words and concepts are also important to learning. Since I’m fascinated with learning and how the brain works, I’ll add this to my reading list.
Getting Things Done: The Art of Stress-free Productivity by
David Allen – Although I never read the book, I felt like I follow a similarly described organisation system. The GTD method is almost like a cult, but requires a lot of discipline for it. Unlike keeping a single list of things to do, they have a systemised variant for keeping long-lived projects and ways of managing tasks to help you focus on getting through actions. Probably a good book if you want to focus more on breaking things done into smaller steps.
The Checklist Manifesto: How to Get Things Right by Atul Gawande – With lots of examples from the healthcare industry, a reminder that useful checklists can help us avoid making simple mistakes. For me, the idea of standardised work (a lean concept) already covers this. I agree with this idea in principle, but I’m not so sure the book covers the negative side effects of checklists as well (people getting lazy) or alternatives to checklist (automation and designing against error/failure demand to be begin with).
Connect: The Secret LinkedIn Playbook to Generate Leads, Build Relationships, and Dramatically Increase Your Sales by Josh Turner – Either a terrible summary or a terrible book, this blink gave advice about how to use LinkedIn to build a community. Although the advice isn’t terrible, it’s not terribly new, and I didn’t really find any insights. I definitely won’t be getting a copy of this book.
Start With Why: How Great Leaders Inspire Everyone To Take Action by Simon Sinek – A nice summary of leadership styles and rather than focusing on how something should be done, and the what, is starting with the why. I liked the explanation of the Golden Circle with three concentric circles draw within each other, with the Why being the starting point that leads to the How that ends in the What. It’s a good reminder about effective delegation and how powerful the Why motivator can be. I’ve added this book to my reading list to.
This is a great introduction to Cloud Concepts!Learn more about our Scrum and Agile training sessions on WorldMindware.comPlease share!
Advanced training for leaders, executives and change agents working in Agile environments.
Your success as a leader in an Agile organization requires looking beyond Agile itself. It requires a deep understanding of your organization and your own leadership path. To equip you for this journey, you will gain a strong foundation in understanding organizational culture. From there, you will learn key organization and leadership models that will allow you to understand how your organizational culture really works.
Now you are ready to start the journey! You will learn about organizational growth – how you may foster lasting change in your organization. Key is understanding how it invite change in a complex system. You will also learn about leadership – how you may show up more effectively. And how to help others.Learning Objective(s):
Though each Certified Agile Leadership course varies depending on the instructor, all Certified Agile Leadership courses intend to create awareness of, and begin the journey toward, Agile Leadership.
Graduates will receive the Certified Agile Leadership (CAL 1) designation.
See Scrum Alliance Website for further details.Agenda: Agenda (Training Details)
We create a highly interactive dynamic training environment. Each of you are unique – and so is each training. Although the essentials will be covered in every class, you will be involved in shaping the depth and focus of our time together. Each learning module is treated as a User Story (see photo) and we will co-create a unique learning journey that supports everyone’s needs.
The training will draw from the learning areas identified in the overview diagram.Organizational Culture
“If you do not manage culture, it manages you, and you may not even be aware of the extent to which this is happening.” – Edgar Schein
- Why Culture? Clarify why culture is critical for Organizational Success.
- Laloux Culture Model: Discuss the Laloux culture model that will help us clarify current state and how to understand other organizations/models.
- Agile Culture: Explore how Agile can be seen as a Culture System.
- Agile Adoption & Transformation: Highlight differences between Agile Adoption and Transformation.
- Dimensions of Culture: Look at key aspects of culture from “Reinventing Organizations”. Where are we and where might we go?
- Culture Case Studies: Organizational Design: Explore how leading companies use innovative options to drive cultural operating systems.
- Theory X – Theory Y: Models of human behaviour that are implicit in various types of management systems.
- Management Paradigms: Contrast of Traditional “Modern” Management practices with Knowledge worker paradigm.
- The Virtuous Cycle: Key drivers of success emergent across different high-performance organizational systems.
- Engagement (Gallup): Gallup has 12 proven questions linked to employee engagement. How can we move the needle?
- Advice Process: More effective decision-making using Advice Process. Build leaders. Practice with advice cards.
- Teal Organizations: Explore what Teal Organizations are like.
- Leading Through Culture: How to lead through culture so that innovation and engagement can emerge.
- VAST – Showing up as Leaders: VAST (Vulnerability, Authentic connection, Safety, & Trust) guides us in showing up as more effective leaders.
- Temenos Trust Workshop: Build trust and charter your learning journey. Intro version of 2 day retreat.
- Compassion Workshop: How to Use Compassion to Transform your Effectiveness.
- Transformational Leadership: See how we may “be the change we want to see” in our organizations.
- Leading Through Context: How to lead through context so that innovation and engagement can emerge.
- Leadership in Hierarchy: Hierarchy impedes innovation. Listening and language tips to improve your leadership.
- Working With Culture: Given a Culture Gap. What moves can we make? Work with Culture or Transformation.
- Complex Systems Thinking: Effective change is possible when we use a Complex Systems model. Cynefin. Attractors. Emergent Change.
- Healthy “Agile” Initiatives: How to get to a healthy initiative. How to focus on the real goals of Agile and clarify WHY.
- People-Centric Change: The methods we use to change must be aligned with the culture we hope to foster. How we may change in a way that values people.
- Transformation Case Study: Walkthrough of how a transformation unfolded with a 100 person internal IT group.
The post Announcement: New Leadership Training – First in Canada! appeared first on Agile Advice.