Now is the time! If you are looking to build a library of video tutorials for remote teams, the first step is creating a plan, and that plan should include best practice production. Have a look at this fun and engaging tutorial about video production by our very own Jon Kneeland. While these are challenging times for all of us, keep going and keep collaborating during the pandemic.
Letting Go of the Formality
It wasn’t that long ago that suits, ties, knee-length skirts, heels and pantyhose were required wardrobe staples. In fact, many enterprise Fortune 100s upheld a formal dress code as part of their HR Policy Handbooks. Goldman Sachs, the last bastion of formality on Wall Street, finally relaxed its dress code and offered a “flexible style” option. They only did so last year. Their updated policy permitted men to choose garments other than suits. Admittedly, this made things more complicated for women but that’s a topic for another blog.
Since we’re agile practitioners here at InRhythm, it made sense to look at our own approaches to talent and acquisition. Not to mention retention. Practices and policies drive corporate culture. Here, Agile Platinum Principle One: resist formality, must serve as one of the pillars of our talent strategy.
If your company doesn’t offer a culture that’s aligned with the needs and expectations of today’s job seekers, then, as Hiring Manager or Chief People Officer, you’re going to have a really hard time. At best, you’re going to struggle and slog through your days and recruiting campaigns. At worst, you’re not going to have any people to serve as Chief over!
The link between informality and tech
Ask anyone within the technology field, or external to it, to describe or draw a person in tech, be it a software developer or a startup founder. The universal response is a male, typically Caucasian, dressed in sloppy jeans and a hoodie. Where did this level of informality originate?
Many would cite Lou Gerstner’s (former CEO of IBM) decision to roll out “casual dress.” Even the New York Times balked with a headline that read, “Black Jeans Invade Big Blue.” Shortly thereafter, Hewlett Packard (HP) introduced “Blue Sky Days” which permitted employees to wear jeans to work on Fridays. From there, dress code devolved or evolved – it depends on your perspective – into what we see today.
However, the Platinum Principal of resisting formality is not restricted to dress code. It extends into everything that we do. Formality also has implications with unconscious bias, how we greet and interact with people, the forms that we require candidates to complete and so on. Tone and style go hand in hand.
How are we resisting formality?
We are constantly taking steps to increase our awareness and connection with our prospective employees, candidates, contractors, staff and employees. Efforts are made to understand what they need so that we can craft our talent, acquisition and retention strategies around their needs and expectations versus requiring that they conform to ours. Here, we have embraced an agile culture across the company, not just in our product development efforts.
As agile craftsmen, with respect to HR recruiting and retention strategies, we have adopted an approach that is more responsive than it is prescriptive. Our applications are deliberately designed with brevity in mind to expedite the hiring process. We measure how long it takes from the time that an application is submitted to an open job posting until someone is seated in the role. A conscientious effort, with monitoring, is made to ensure that we are constantly moving our candidates through the hiring process as swiftly as they seek to do so.
Another way that may come as a bit of a surprise is the effort we make to create a relaxed culture that allows for flexibility and downtime. We understand the enormous pressure and stress that our employees feel as they do all that they can to deliver on our clients’ needs. It’s okay to push through a couple of scrums or back-to-back sprints but it’s not sustainable. Over the holidays, we relaxed with an in-house office party and gave people some bonus time. This week is Valentine’s Day: celebrate it or not, you don’t need to make it about sending flowers and chocolates to your partner. Use it as a reminder to resist formality, take some time and reach out to whomever it is that you care about, be it a parent or sibling or a friend.
Resist formality! Make strides to emulate the people and culture around you. Forcing people into a process defined by its rigor and inflexibility is the antithesis of what a company should do. Particularly a company who’s purpose is to bring agile methodologies and success to our clients.
Stu Weiser,
Director of Talent Acquisition
Image created by katemangostar – www.freepik.com
Unleashing The Potential Of Your Offsite Team
Thriving vs Surviving
Are You Unleashing Your Team’s Potential? Or, are you an engineering Practice Lead or Manager who’s unconsciously capping your team’s potential? While there may be the odd diabolical leader who intents on deliberately holding his or her team back, I like to think that doing so is not the norm. Leaders of agile craftsmen want their teams to flourish and fly through each sprint. Doing so will require creating an environment and work culture that fosters improvement and unleashes a team’s potential.
With a new year and decade here upon us, the idea of making resolutions to catalyze changes isn’t new. It’s a centuries-old tradition that has begun to fall out of favor. Given that < 8% of us make it through the year, performance and motivation coaches suggest that we set goals for the year instead of resolutions. By setting a goal, we know which direction we’re headed for and it allows us to “slip back” or go off-course occasionally yet still track towards the goal unlike resolutions, which do not offer the same latitude.
Here at InRhythm, we’re looking forward to achieving continued success in 2020. With increased efforts to build and empower our 10x teams and to better enable our clients, we have set several key goals for the year ahead.
2020 Goals
- Continue to put our customers first and make every effort towards 100% customer satisfaction
- Foster a culture that truly embodies the Agile Manifesto
- Grow our footprint in new markets and industries
As the Practice Lead , I’m conscious of how well my team is performing and how the toll of being onsite at clients’ workspaces affects them. I’m also aware that I need to give the team space to work together on a sprint and to figure things out on their own. When they hit an obstacle or begin struggling with forward progress, that’s the time to jump in. Until then, leaders must encourage their teams to experiment and err, support them, and back them when the choices they’ve made may not be the ones anticipated by their employer but they’re exactly the right ones needed for the client.
In addition to giving your team some latitude and space so that they can creatively solve problems without you helicoptering over them, you also need to think about giving them recognition. Of course, nobody wants to celebrate repeated failure, but, if a software developer made an informed decision to try to do something in a new way and everyone could extract lessons learned from that effort, then s/he/they should be celebrated for making a bold move and trying to do something different. It should go without saying that the successes also need to be celebrated. Recognition motivates teams to try harder.
Efforts in the opposite direction will have – no surprise – the opposite effect. For example, a lack of recognition for doing well or finger-pointing when there is an error will demotivate teams and start to put restraints on their ability (and desire) to flourish. Powering up 10x teams requires motivation and support so that members can dig deep and unlock their potential. Motivation should be a weekly or monthly focus and not reserved for the one day each year when companies formally recognize their employees, clients or management team.
Here at InRhythm, we’re encouraging more dialogue between members and practice leaders and added the role of a liaison designed to facilitate open and honest discussion. We’re creating a culture where it’s safe to respectfully voice an opinion and to try new things that could make a difference for our clients. It’s also about accountability. If a team member come forward and voices a concern or a need that does not get addressed with an effort towards closed-loop communication, that member’s potential becomes thwarted.
Have you made 2020 all about your team’s potential? Are you subconsciously thwarting it or actively boosting it? Be the practice leader that helps teams thrive – not just survive.
Change? What Change? Everything Always Goes to Plan
As software engineers, we are conditioned to brace for change. The very nature of our work requires that we be ready for it. Yet, at our cores, we don’t want there to be any changes. We don’t surrender to the inevitable changes that are going to be required after we submit content for a code review. Instead, we steel ourselves against it, and gear up for battle with a mindset of resistance. We don’t want our QA teams to find any bugs because we’ll then have to make changes to the code we’ve already written.
The experience, however, is like the Grinch who does everything that he can to stop Christmas from coming. Of course, the holiday arrives anyway. Similarly, despite our best efforts to plan and design an agile effort which builds change in, we’re still not entirely prepared to embrace those changes when they do come. And they will. They always do.
Agile Value #4: responding to change over following a plan” speaks to this behavioral response. It’s all about our attitude. Are we prepared for change and willing to accept that there will be change (as there is for every software engineering project)? Or are we preparing for a fight that we are inevitably going to lose?
Agile craftsmanship requires that we be nimble in our designs and in our approach. The code we write must stand up to meet the quality demands of the project and not interfere with other parts of the project, but it has to be nimble, too. Anyone at any time in the future may need to rework that code or replace it altogether. If it’s rigid and inflexible, the effort to update it (or replace it) will be that much more intense. Working sprint after sprint is already intense enough – we don’t need to add more stress to our day. In contrast, we need to take measured steps to reduce it.
One of the best ways to manage this stress and to reduce our anxiety is to prepare for change. Embracing a mindset of flexibility prepares us for the change that is coming. If our response is calm and collected, the changes requested will be received just like any new project instead of what may feel like a personal attack on our abilities.
Approaching any project with the expectation that it will likely end differently than it began requires proactively building a roadmap that is designed to be nimble and responsive by anticipating potential changes. Getting ahead of industry trends and predicted needs requires that we are constantly in the mode of collecting feedback from clients, tracking the market and soliciting input from other agile experts. Scenario planning is another way to help with preparedness. This is the only way that we can evolve as a trusted colleague and partner to the clients we collaborate with.
Christopher Okhravi, an authority on agile software development, offers an insightful perspective on the application of Agile Value #4. He reminds us that, “We should never forget that they [the clients] are the ones asking for the system. And they are the ones who will ultimately use it.” Another factor that we need to remember is that rigid planning and process are the antithesis of the freedom derived from an agile approach. As each project unfolds, we learn more about the needs of that project and gain new insights on how to best deliver the code needed to execute the project. However, as we do so, we tend to drift further from the original plan which no longer reflects our reality and this creates tension for everyone involved.
So, what is the best way forward? Embrace Agile Value #4. We must plan for the worst but hope for the best because change is inevitable. We must be nimble – and stay that way. Change is a necessary element of what we do. We can design our product roadmaps to be responsive and proactive or we can choose to be reactive and struggle to keep up. Getting ahead of industry needs and trends helps us prepare for the changes that will come. Being open to continuous feedback from our clients, our managers, our peers and our colleagues helps us evolve into a trusted co-worker and business partner.
“Change always comes bearing gifts.” ~Price Pritchett
Robert Morrell
Practice Lead, Java Cloud
What We’re Reading Around the Web
Agile Manifesto 4/4 – Responding To Change Over Following A Plan by Christopher Okhravi
YouTube
“We should never forget that they [the clients] are the ones asking for the system. And they are the ones who will ultimately use it.”
Manage Stress
Healthfinder
“To be agile, you need to be able to ask, ‘Is this agile?’”
Applying Agile Management Value 4: Responding to Change Over Following a Plan
Dummies
“Unfortunately, traditional project management approaches attempt to wrestle the change monster to the ground and pin it down so it goes out for the count.”
Getting Started With Agile: Responding to Change Over Following a Plan
Pivotal Tracker
“As project execution unfolds, the team learns more about what needs that resulting product will fill as well as how that product can best be built. As this new reality emerges, the team struggles to keep their project aligned to the original plan, which likely no longer reflects the team’s new reality.”
Practice What You Preach
As agile practitioners and thought leaders in software engineering, when we work onsite at our clients’ offices, it is important that we deliver our best. After all, as consultants, we are viewed as experts brought in with the expectation that we instrument and equip them with high velocity teams. In this regard, as we heard from our CEO, Gunjan Doshi, in last weeks Learning & Growth Newsletter, we are agile craftsmen. Our challenge is how we can balance learning on-the-fly while integrated onsite with our clients and managing their project expectations.
It is one thing to operate as a living lab when you are shielded inside the walls of your company’s office. With the right culture, mistakes will be expected and valued. When they result in a learning opportunity they ultimately drive a new insight into efficiency and judgement, however, when you are working onsite with a client, it can be an entirely different experience. Mistakes can result in injured productivity or be viewed as an inhibitor to progress and improving velocity.
Clients understand that software development is partly intuitive as much as it is scientific, and even masters of the craft will occasionally misjudge. Agile methodologies instill the mindset that we constantly iterate upon and improve our solution as well as our process. This not only holds true in what we craft, but also from within ourselves. As agile craftsmen it is our responsibility to analyze our own efforts, understand and mitigate risks, decipher inefficiencies in complexity, and test and implement modern approaches, all on behalf of our clients.
As each of us continues on our own path of learning, an opportunity to support each other within our living lab presents itself. We are a community traveling in the same direction. Such says the African proverb, “If you want to go fast, go alone. If you want to go far, go together”. We are bar-raisers and we travel together. In this sense, all of our clients can benefit from any of our thought leaders.
There will be times where we struggle. Perhaps, through a buggy release or during the release of a new product with unanticipated difficulty. We must take feedback with fortitude and cannot be afraid to pivot our strategies, evaluate new implementations, test and ultimately learn.
Learning by doing is often the best form of instruction. Agile craftsmen must recognize that failure is a part of the development process. As Robin Arzon would say, “Failure is the platform to which we build upon”. Often times success only provides validation and feedback is an essential aspect of agile development supporting the continuous loop through which we design, implement, test, and learn.
Earlier this summer, the much anticipated release of Apache Kafka 2.3, a vastly popular component in microservice architecture, enabling streaming and real-time processing of records, was met with its own challenges. One of the persistent bugs was related to the user unsubscribe functionality. This was obviously a critical part of their offering today given the growing requirements related to data privacy and simply an essential aspect of any offering to ensure customer satisfaction. I’m sure everyone will agree, in today’s modern service oriented technology landscape, that the customer is in control and products must incorporate their needs if they wish to remain in business.
It’s simply not easy to project our own living lab culture when onsite with a client. The pressure is already high to meet deadlines and each of our own efforts is codependent on others’ to execute and deliver. Another factor can be pride. Nobody wants to err and be labeled as the bottleneck.
So how will you manage to accomplish this? Observation and communication. Follow what the signs say in the subway stations and airports. “If you see something, say something.” This is actually universal advice and is highly applicable to agile development efforts. By remaining sharply aware of what you’re doing and how that work is impacting those around you, your sprint, project, and team, you will be in a better position to anticipate potential challenges and outcomes. You can then communicate these as you predict them or as they are happening so that you can work collaboratively with your client and your colleagues onsite to address them. Sometimes simply managing expectations can afford you the opportunity to make mistakes, and as we know, making them earlier saves future development efforts.
Failing is a part of the process and not having the visibility and foresight to identify and cross-communicate about potential issues creates risk and impedes high-velocity teams. Agile craftsmen are expected to be nimble minded, to think and learn fast. We are expected to err on occasion and it’s all about how we handle that situational awareness and how we are communicating to others so that we all learn and grow together.